Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

Dark GDK / Problem with getting vertex locations

Author
Message
prasoc
15
Years of Service
User Offline
Joined: 8th Oct 2008
Location:
Posted: 9th Oct 2011 19:13 Edited at: 9th Oct 2011 19:16


When I set object 1 to be a dbMakeObjectSphere or something, the vertices come out fine where they should be. But as soon as I replace object 1 with a .X file, the locations are all off: with one object only half of the vertices actually come up, another they are in the completely wrong places, etc. Why doesn't dbGetVertexDataPositionX/Y/Z() actually return the vertex location on loaded objects correctly?

Is there a way of getting the DirectX mesh itself and getting the proper vertex locations? Or am I doing something wrong?
Chris Tate
DBPro Master
15
Years of Service
User Offline
Joined: 29th Aug 2008
Location: London, England
Posted: 9th Oct 2011 19:31
This is puzzling, but it could be that the FVF format of the loaded object is not the same as the sphere's FVF format; try converting the object to the correct FVF format and see if that resolves the problem. If it is a text based .X file, you could also check that the vertexdata locations are valid.




Chris Tate
DBPro Master
15
Years of Service
User Offline
Joined: 29th Aug 2008
Location: London, England
Posted: 9th Oct 2011 19:37
Quote: "Is there a way of getting the DirectX mesh itself and getting the proper vertex locations? Or am I doing something wrong?"


Excuse my double post; but just incase you are using Blender to create the .X files, and you want to create some kind of entity at vertex locations; another trick is to use limbs and take advantage of the limb commands. The limbs can be created using the DupliVerts feature in blender, which creates a limb (a mesh or empty) at all vertices (which can be exported after making Duplicates Real [Shift Ctrl A]

prasoc
15
Years of Service
User Offline
Joined: 8th Oct 2008
Location:
Posted: 9th Oct 2011 20:23
I've just tried the FVF flags, what do the inbuilt shapes have as their FVF? also, is dbMakeMemblockFromMesh() a simple way of getting the vertice data? (I need to look up the commands for memblocks, seems pretty complex)
Chris Tate
DBPro Master
15
Years of Service
User Offline
Joined: 29th Aug 2008
Location: London, England
Posted: 9th Oct 2011 20:49 Edited at: 9th Oct 2011 20:50
Quote: "what do the inbuilt shapes have as their FVF"


I wrote an article about this actually:

Usually without a diffuse colour the format is FVF 274; otherwise FVF 338. You can check this using the first DWord in the memblock.

Quote: "
is dbMakeMemblockFromMesh() a simple way of getting the vertice data?"


Not really, the vertexdata commands should be the correct and easiest way; if things work. The memblock approach isn't the fastest, but it will show you all of the vertex positions; it has to because it just outputs the values sourced from the .X file into the memblock.

prasoc
15
Years of Service
User Offline
Joined: 8th Oct 2008
Location:
Posted: 9th Oct 2011 21:19
ehh 274 and 338 don't do anything to the vertex positions that are output from vertexPositonXYZ() :/ ill look over your article and probably have to end up using memblocks, thanks
Matty H
15
Years of Service
User Offline
Joined: 7th Oct 2008
Location: England
Posted: 9th Oct 2011 22:22
There may be an issue with your code.

There is an official command dbLimbCount() now. I have had strange results before using the check list. Also you don't seem to be unlocking the vertex data for each limb, dbUnlockVertexData().

Try that, if nothing helps, could you post the model?

prasoc
15
Years of Service
User Offline
Joined: 8th Oct 2008
Location:
Posted: 9th Oct 2011 22:56 Edited at: 9th Oct 2011 23:06
Changing the checklist for dbLimbCount does nothing, and I just uncommented dbUnlockVertex and it also does nothing :/

Using memblocks, I've managed to get (supposedly) the vertex positions, but the x,y,z values are huuuge! Wayy outside of what they should be. Anyone crit this code?



edit: I realised it was dbMemblockWORD and not dbMemblockFloat(), the values for XYZ are much smaller now, but now they're TOO small :/ I'm not scaling the object either, no idea whats going on

edit2: I've worked it out. Turns out its 28 byes + 4 for the last DWORD haha, the vertex positions seem to come out fine now Thanks for your help everyone!
Chris Tate
DBPro Master
15
Years of Service
User Offline
Joined: 29th Aug 2008
Location: London, England
Posted: 9th Oct 2011 23:06
Hmm, if geometry is smaller than it should be in the engine, the .X exporter may be scaling things down. 1 unit in your editor should be 1 unit in the engine.

prasoc
15
Years of Service
User Offline
Joined: 8th Oct 2008
Location:
Posted: 9th Oct 2011 23:10 Edited at: 9th Oct 2011 23:13
It turns out that every vertex I went through, I was missing out the last 4 bytes xP meaning that over time it would just use ANY values for the positions! its 32 bytes between vertices not 28! Thanks for the memblock tutorial help
Chris Tate
DBPro Master
15
Years of Service
User Offline
Joined: 29th Aug 2008
Location: London, England
Posted: 9th Oct 2011 23:13
I think these should be dbMemblockWord(1,12+j*32) and not j*28. It is a bit faint on the diagram where it says 'To 32', but positions 28-32 are the 4 bytes for the V texture coordinates. The following vertex is at the offset of 32 onward.

Are you changing the size of your spheres from 5 to 50 now? In the original post the spheres where size 5.

Chris Tate
DBPro Master
15
Years of Service
User Offline
Joined: 29th Aug 2008
Location: London, England
Posted: 9th Oct 2011 23:14
prasoc
15
Years of Service
User Offline
Joined: 8th Oct 2008
Location:
Posted: 9th Oct 2011 23:16
Yeah, I was just testing out the sphere sizes to see where they actually were :L the whole spheres thing was just to debug it anyway, but it's fixed so I dont need to see them anymore
Matty H
15
Years of Service
User Offline
Joined: 7th Oct 2008
Location: England
Posted: 9th Oct 2011 23:44 Edited at: 9th Oct 2011 23:47
Have you got it working?

I just thought on, I don't think you can access the global vertex positions directly. I think you need to transform them with the limb matrix, it's not as hard as it sounds with:
dbGetObjectWorldMatrix().

EDIT: Or make a new object from the object mesh and all limbs disappear and it should work if the object is at 0, 0, 0 with no rotations applied, I think?

prasoc
15
Years of Service
User Offline
Joined: 8th Oct 2008
Location:
Posted: 10th Oct 2011 00:19
Yes I have got it working. Just used memblocks instead of the built-in vertex commands! Had to change the object into a mesh first though, works fine now

Login to post a reply

Server time is: 2024-05-04 06:46:51
Your offset time is: 2024-05-04 06:46:51