DeleD Community Edition

[_kohai]

Hi all !

Ok, i'm making some nice progress on my .dmf openGL reader, but i have a few questions:

- after reading a bit through the forums, it comes out that DeleD saves its vertex in integer format ... is this still the case ?

- Does DeleD only outputs Quads ( so far, i've only seen 4 vertex polys in .dmf )or some triangles might show up at some point ?

- the output for material infos are :

ID, name, category, reserved, # of texturelayers, layer.type, layer.texturefilename, layer.blendoperation
Then you say : If your material uses the first and last texturelayers, a ; character for each layer in between is still stored in the file.

OK good ... but if i have texLayer1;[null];[null];LightmapLayer, does the material indicates 2 layers or 4 ??? In short, are the 2 null layers still taken into account ?


Thx for clarifying these issues a bit ... it could help me finishing my stuff quickly ...
Keep up !

[Daaark]

If you have quads, the file contains quads. Trinagulate your level to get triangles.

[_kohai]

errr ... clever answer for sure !

Ths thing is, it seems DeleD only outputs Quads ... If that's the case, there no need to make some triangle conversion routine ...

So no need to check vertex count for faces ( cos fixed ), and such things ... Little hints that make programming easier, and help avoiding bloated code !

thx

[CMe]

Hi there,

ok DeleD outputs vertices as floating point values at the object level and then each polygon face uses indices to these vertices. This however doesn't apply to texture coordinates which are stored in the polygon list after the indices. Each polygon isn't limited to being just quads. It can have an arbitrary list of vertices. These can be rendered in opengl using triangle fans or you could triangulate the faces.

Regarding the material layers, as far as I can tell, the null layers are redundant. I'm not sure however why they are there in the first place. Only thing I can think of is that the DeleD developers wanted to always have lightmaps stored in the fourth material layer. I'd like to find this out for sure myself.

If you need any help or some code example, give me a shout. I'm planning on releasing my DeleD parser which is pretty much done. I've also got a simple opengl renderer for this as well if interested. All of this is written in pure C.

As a side note, I recently plugged in my parser into FSRad radiosity processor and it managed to generate correct lightmaps so I'm quite confident the parser is working. Would anyone be interested in me working with this further?

[CMe]

a small correction to my above post. actually, the file does store vertices as integers. I just interpret them as floats when parsed.

[BorisTSR]

a polygon in deled can have a more or less vertices than 4. what the first replier meant is, select all your scene, then select the tool "Triangulate" and then select what mode of triangulation in the tools properties area. this will turn every non triangle polygon into a triangle.

[Paul-Jan]

CMe, hope I am not spoiling the fun of researching this for you, but you were right about us always storing the Lightmaps in the 4th layer This way of storing things (with empty layers in between) is a simple alternative to layer indices that directly reflect the way things are presented in the GUI (i.e. fixed layer slots, that can be empty or not). Of course layer indices would have been elegant. Or special layer markers. Or whatever. Anyways, this is what we choose

Loading the vertice coordinates as floats is a smart thing to do, as we will probably move over to floats in the not too distant future.

Also, if you want to look at example C/C++ parser code, you can always take a look Ill Buzzo's loader and the Irrlicht engine.

_kohai, as a quick recap of what I said before: in your case, the material would have 4 layers in DeleD, of which only 2 are used. However, your specific application is of course free to ignore any empty layers it encounters!

[Paul-Jan]

As a side note, what Vampyre meant to say is that wether you have quads or not depends on the primitives you used. Most of 'm are made up of quads, but there is also the polyline, the pyramid and the text primitive. All of these will result in non-quads on screen, thus non-quads in your file

[_kohai]

Okaaay ....

Well, first thx for all these infos !

And i apologise to Vamyre_Dark as i got his words the wrong way ! Sorry, mister ...

Ok, so i'll triangulate the .dmf before exporting. Having variable polygon vertex is not a good idea, when it comes to Vertex Array and such ... So i'll go that way


CMe > yeah, i'm storing vertex as Floats also, but it would have been a bad implementation ( dynamic memory wise ) if only Integer were used in .dmf format. Anyway, as the format is subject to evolve, i'll keep them as floats
And yes, i'll gladly have a look at you .dmf parser implementation !
I'm not yet to the display part ( still working on the bug-proof parsing ). Just as a side note :
You use display list, vertex array, vbo ?

Again, thk you all, and see you in a while, hopefully with a working loader

[CMe]

[Jeroen]

[CMe]

Hi Jeroen,
sure I'd be happy to release the parser for download on the site. I do have a few questions regarding the format though that I'd like to clear up before I'm done.

1. why is the quadratic value in lights written to the file in scientific notation? I didn't notice this until I wrote routines to write a dmf file.
2. does the preserve ratio boolean for objects actually do anything? doesn't appear to be stored in file?
3. is there any planned usage for the reserved field in the material description?
4. any reason why the visibility flag is stored as negative 1 for visible instead of positive for objects?

Any answers would be great. Let me know how to submit the source. Thanks

[Paul-Jan]

While I'm here, I might as well answer some of those:

Ad 1) It is just the 'general' float format string. That means it will use scientific notation for values below 0.00001. We assumed most languages would offer default float parsing routines agnostic to notation, isn't that the case?

Ad 2) I hope Jeroen has something sensible to say on this one

Ad 3) [edit]The information given here is false, please pretend not to see it[/edit]

The 'reserved' field is no longer reserved, the file format description is lagging behind

- If that field is 0, the material layer contains a texture, and the next value is the texture filename relative to the DeleD texture folder.

- If that field is 1, the material layer contains a color, and the next value is the hex value of that color (i.e. 00FFFFFF would be white).
[edit]End of false information[/edit]
Ad 4) It's the Delphi default for storing booleans (i.e. BoolToStr). It's not my favourite either, but it isn't too bad. Anyway, the reverse conversion is pretty flexible, it will turn any non-zero value into 'true'. You might want to take the same approach

[Paul-Jan]

Oh btw, there is a slight technical advantage of using '-1' for storing boolean true: the bitwise 'not' operator automatically becomes the logical not operator.

(

to elaborate:

- if you use 1 for true, not (true) == not (1) == not (0x0001) == 0xFFFE == -2 == true
- if you use -1 for true, not (true) == not (-1) == not( 0xFFFF ) == 0x0000 == 0 == false

)

[BorisTSR]

the file formate description for materials is: