Quote:
|
Originally Posted by jbb
A few more comments and questions on your document.
It's looking good but I have some questions...
Alignment - It might be a good idea to require that atoms start on a 4 byte boundary as it's very painful to read longs at non aligned addresses on some architectures and slower even on x86.
Poly structure - I'd suggest having a Material id rather than a Texture id as you need to have more than just a single texture for anything but the simplest case. (Detail textures, Normal Maps, Shader effects, etc...)
Do you really want to require big endian numbers given that probably 90% of people use x86 machines? Guess it doesn't matter all that much.
Is the "octr" atom optional for the "wld-" atom? Or is it required to make an octree? If so will a simple octee with everything in the root node do? (I'm thinking you might not want to rebuild it all the time while testing stuff out)
Can an "obj-" atom not have an octree? I'm thinking that if you have transparent textures in the model you'll need to depth sort to render it and an octree could speed this up potentially.
Is there any reason to have wld and obj atoms being any different?
Is the obj- atom really a model - and you'll somewhere else have something to place multiple instances of this model in the world?
Sorry for all the questions.
Also I see you have specified double. it's more usual to use float types for this kind of thing, is that deliberate?
|
Hrm... thank you for pointing out some really stupid flaws in my logic hehe.
First, I don't think that alignment is that big of a deal, and will just overcomplicate the file format. We're talking about such a slight bit of overhead that it's not even worth considering since it's only at loadtime. Also, the reason I suggest big-endian for everything is that we can simply use htonl/ntohl to do the conversion rather than having to code our own byte-swapping function. Makes it simpler to port to other archs.
The polygon texture ID really is a material ID since it references the tex- atoms which are materials under the guise of normal textures hehe.
Yes, all wld- atoms should have an octree, if only a single end node containing the polygons. And the reason the wld- and obj- atoms are seperate is because the obj- atoms contain a name.
obj- atoms don't have an octree because for such a small polygon count, it's simply not neccesary. It'd just add bloat.
And thank you for pointing out that we need a way to place objects... it completely passed over my head while we were designing it hehe.
So, I'll fix the docs in a sec.
Threaded Mode
