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.

Newcomers DBPro Corner / Memblock Mesh format questions

Author
Message
Neuro Fuzzy
17
Years of Service
User Offline
Joined: 11th Jun 2007
Location:
Posted: 16th Oct 2008 05:51
I'm trying to edit an object using memblock meshes. The one thing i don't get, is the difference between bytes, words, dwords, and floats. The problem isn't what they are, it's how to specify them. What i dont get, is if these are all in the same "Line" or if they have seperate rows.
byte byte byte byte | byte byte byte byte

So, if all you needed informationwise was the information stored in the bytes, you would just set bytes 1-8
but if you set float 1, that would be the first four bytes.

OR

byte byte byte byte byte byte
float float float float
dword dword dword dword dword
word word word word word word

So, if you uset SET MEMBlOCK BYTE memblocknum, 1
that would have no effect on the first float.
???

Slayer93
20
Years of Service
User Offline
Joined: 5th Aug 2004
Location: I wish I knew
Posted: 16th Oct 2008 06:13
Quote: "So, if you uset SET MEMBlOCK BYTE memblocknum, 1
that would have no effect on the first float."


I think you mean write memblock byte and that takes three parameters. I think the parameter your missing in your logic is the position parameter.

The position moves through the memblock by bytes. Floats take 4 bytes and if it was at the beginning you would move past those 4 bytes (assuming you don't want to affect the float value) and write your byte in position 4 (position starts at 0 so 0 to 3 would be the float and position 4 would be your byte).



Neuro Fuzzy
17
Years of Service
User Offline
Joined: 11th Jun 2007
Location:
Posted: 16th Oct 2008 06:27 Edited at: 16th Oct 2008 06:27
Okay, thats what i originally assumed

and the quote was a typo, im not too familiar with those commands.

So "
WRITE MEMBLOCK BYTE memblocknum, 0, 100
WRITE MEMBLOCK WORD memblocknum, 1, 1312
WRITE MEMBLOCK DWORD memblocknum, 3, 1312
WRITE MEMBLOCK WORD memblocknum, 7, 1312"

none of those values would overlap or erase the other's data?
Gotcha.

Slayer93
20
Years of Service
User Offline
Joined: 5th Aug 2004
Location: I wish I knew
Posted: 16th Oct 2008 06:39
No those wouldn't overlap at all.

Neuro Fuzzy
17
Years of Service
User Offline
Joined: 11th Jun 2007
Location:
Posted: 16th Oct 2008 07:31
Hmm, im running into an interesting thing here. I don't know if it's an error, but if anyone knows why this is happening i'd appreciate it.

this code makes a sphere, turns it into a memblock, and then gets the x and y values only and pastes them on the screen. What interests me is that there appears to be some "Outliers" in the image. It should be a series of points that form the rough shape of a circle, but instead some points are outside the "Circle"
Also, the third float is supposed to be the number of vertexes in the model. The number i retrieve from
total= memblock dword(1,8)
is 930
The value i recieved through trial and error is 827 vertices.

BatVink
Moderator
21
Years of Service
User Offline
Joined: 4th Apr 2003
Location: Gods own County, UK
Posted: 16th Oct 2008 11:51
This is not mine, but I have obviously archived it at some point from a forum post:

Quote: "a brief explanation of memblocks containing meshes. I guess you're using DBC, so I'll use that format.

After taking a quick look at the help files, it turns out I've never used the DBC memblock mesh commands anyway, so I'll just have to make it up as I go along.

Ok, the first 32 bytes in the memblock is the header, which contains:

(0) Number of vertices
(4) Byte offset to vertex data
(8) Number of normals
(12)Byte offset to normal data
(16)Number of faces
(20)Byte offset to face data
(24)Size of all face data
(28)Offset to texture coordinates

All these values are 4 bytes (dwords), that is how they are read and written. Having never used the commands before, I can't tell you if the byte offset is from zero or 32 or what, you can probably establish that from experimenting. The numbers in brackets are the positions in the memblock in which you write the data.

Now, the data after that is what you use to create your mesh. You can set any number of vertices, and link up three at a time to make a face. Each vertex in a face has a normal, but the vertices and normals are kept as separate data. The normal of the face is probably calculated based on the average normals of the vertices making up that face. Now, starting at position 32, you can input vertex data, as 4 byte floats. You input 3 floats per vertex, to hold the X, Y and Z positions of the vertex.

'n'th vertex:

(32+(n*12)+0) X position
(32+(n*12)+4) Y position
(32+(n*12)+8) Z position

You can input as many of these as you like, just make sure to put the appropriate offset in the header.

Now, you can create some normals to help light your mesh. A normal is basically a vector that points outwards from the surface of the mesh. (I hope you know what a normal is, that explanation was rubbish). You can set the X, Y and Z components of a normalised normal vector in the memblock.

'n'th normal:

(32+normal offset+(n*12)+0) X component
(32+normal offset+(n*12)+4) Y component
(32+normal offset+(n*12)+8) Z component

These are all 4 byte floats. Again you can add as many as you like, providing you set the correct offsets in the header.

Now, face data. Each face consists of three vertices, and three normals. Also a number of vertices used, but that should always be set to 3. Now, there is an inconsistency in the help files here. It says the face data should be 2 byte dwords. Now this should either be 4 byte dwords or 2 byte words, I'm not sure which, having never used the commands before. As such, the number in the expression for the memblock position to write to should be (n*14) or (n*28) appropriately. Likewise y should increment in steps of 2 or 4 respectively, like in the previous examples.

'n'th face:
(32+face offset+(n*x)+y) Number of vertices (always 3)
(32+face offset+(n*x)+y) Vertex index A
(32+face offset+(n*x)+y) Normal index A
(32+face offset+(n*x)+y) Vertex index B
(32+face offset+(n*x)+y) Normal index B
(32+face offset+(n*x)+y) Vertex index C
(32+face offset+(n*x)+y) Normal index C

You can define a face by putting the indexes (not the memblock positions) of three vertices, and three normals to use with these vertices.

Lastly, you can input texture data. Each vertex has a U and V value for it's texture coordinates. These come right at the end of the memblock, and are 4 byte floats.

'n'th vertex's texture coordinate:
(32+texture coordinate offset+(n*8)+0) U coordinate
(32+texture coordinate offset+(n*8)+4) V coordinate"


IanM
Retired Moderator
22
Years of Service
User Offline
Joined: 11th Sep 2002
Location: In my moon base
Posted: 16th Oct 2008 15:18
Steve, that's the DBC format, which is different to DBPro's - DBPro doesn't allow you to access indices via memblocks.


Personally, I'd use the vertexdata commands rather than memblocks:


To support that, I've added some commands to my plug-ins in the past that allow you to create a new object with a single linb - you just specify the number of vertices & indices, and an optional FVF format.

Login to post a reply

Server time is: 2024-09-27 20:30:29
Your offset time is: 2024-09-27 20:30:29