Latest specifications.
Features.
Thanks to the following people for being helpful when I go on and annoy about the 3d-format, asking questions and stuff :)
David Larsson, Robin Håkansson, Johan Sten, Obsolete, Anders Bodbacka, Anders Larsson, James, Tovio Henningsson, Peter Edmark, Albert Sandberg, Anders Moden, Dan Nilsson, Tobias Barendt, Patrik Clarberg, Mikael Bergforsen. And of course Karl T. Kalleberg (Ghyll).
I have been thinking alot about the classes that the plugings and the command-line-convertor shall use. This is my current though on the subject:
We will have a virtual Header-class for all formats. I will have a unique header-class for each format (header3DS for instance) that will use the Header-class as baseclass.
We will have a virtual formathandler called Handler for all formats. I will have a unique Handler class for all formats (handler3DS) that has Handler as baseclass.
The handlerFormat object will allocate an headerFormat-object. The headerFormat-object has two methods; convertTo(ourFormat) and convertFrom(ourFormat). The handler has two methods; save(filename, ourFormat) and load(filename, ourFormat).
Load will fill up the headerFormat-object will all data and will then call headerFormat.convertTo(ourFormat).
Save will call headerFormat.convertFrom(ourFormat) and then it will save the file to disc, reading data from the headerFormat object.
Most format will not support the .save-method but only the .load-method.
The reason for this is that several formats can share header-classes. For instance .3ds and .ASC. Also it will make things easier when we are supposed to do both a command-line version and a plug-in version. 3DS-MAX plugin and .ASE can use same headerclass. LWS and lightwave plugins can use the same headerclasses.
We have decided to do lightwave 6.0 bones which are closer to 3ds-MAX bones than lightwave 5.x bones. Lightwave 5.x will be left out for the first releases and implemented later on.
I am thinking about having multiple keyframing per object. That would be good for gameobjects. A guard could have a both "walk" and "run" keyframing. Otherwise two objects must be done. Any suggestions here?
2000-01-07, 03:22
Patrik Clarberg has taught me some about smoothing-groups and texture-coordinates in the .3ds-files. I was right about smoothing-groups with the exception for group 0 which means that the vertexnormals equals the facenormal. Still has to design our smoothing-groups though. Must have a look on 3DS-MAX smoothing groups.
From now on I am in charge of the .DTD-file (specification) from which the sourcecode for the saver-class in automatically generated. Hopefully I can also generate a .HTML-file from it so I do not have to update both the html-specs and the .DTD-file when I make changes. I will put the latest .DTD-file and an example .XML-file up as soon as the DTD is up-to-date and we can save .XML from it (3ds->xml that is).
Hopefully Tobias Barendt will do some of the work with Lightwave-reader. A bones-proposal might be upcoming too.
I saw that Paul Bourke had a proposal for a generic 3d-format in 1994. Seems like we are behind... Well I have never heard of the format so I hope that our will turn out to be more successful. At least I will use it, and that is something, is it not?
A class-view of the format will be up soon too, will take some time though.
We have also decided to slow down the development of the format now so that we can review the format. We will advance slowly. This is also because Ghyll has a deadline the 15th of Januar. Good luck to him!
2000-01-05, 05:01
Converted the entire specification to HTML so that Ghyll (and others) can read it proprely. I failed to remember how much I hated the PRE-tag, but as long as you do not look at the html-code itself it is somewhat nice. It was ok until it was to be colored. The next step is to add more documentation to it. Describing the more troublesome chunks somewhere.
The light-chunk was improved and a distant light (a sun) was added for full lightwave support. A Two-sided flag was put in the material after Dan Nilsson had convinced me that was the way to go.
We have decided to wait with sourceforge.net til we have a proper documentation of the format ready. I think we will very soon. The real project is to do the 3DS-MAX export-plugin without having to change too much of the format; we do not want the format too complex.
The lightwave convertor is not nearly halfdone, but it seems rather easy so it should be ok. Some of the copying and converting will be hard though. I am afraid we cannot save to lws/lwo from our format after conversion. Converting to 3DS-MAX (.ASE and import-plugin) and perhaps even .3DS should be possibly, but not .LWS/.LWO.
2000-01-05, 02:04
After just sitting around doing nothing the whole day (not quite true, but almost) I started doing the first version of the lightwave loader. The .LWS-files turned out to be text-files (actually I did not know) so now I am doing the reader for them. I still have not decided wheather I should support envelopes or not. I must if I want to be able to keyframe the light-intensity and perhaps some other less important things. I suppose I will support them. What really scares me is that I have to read the .LWO-files too. They seem scary :)
Robin Håkansson has promised to help me out with the bones in lightwave and I think that we will have a preliminary version of the bones in our format-description very soon. Still got to know more about 3ds-MAX bones thought.
I have been looking around at www.sourceforge.net today. Seems rather nice. I have asked Ghyll if we should not move the project there now. We will see how it end up. If we do so they will give us surveys, cvs-servers and some other things we could be without but might like. Also it make create some new users/developer which might speed things up. At first we would only publish the format itself and ask for improvements. Then in a month or so we start putting the sourcecode there too, in a nice cvs-tree.
And this .plan-file too ofcourse as they provide us with 100 mb of space. Well we still got to see if they approve of our project too.
It might be too early though. But it would be nice hearing others opinion on the format before we code all the utilites. I have heard some opinions, but I want a bigger userbase than 10 people :)
Apparantly we can have recrusive chunks so the BSP-chunk can be considered to be ok. We might add bounding-volumes though (sphere and box). Perhaps a bounding-teapot would be nice.
I am changing the portal-chunk a bit. Now bsp-trees and portals should go along too.
2000-01-04, 19:00 [Hiarchies and smoothing groups]
After some thinking I know how hiarchies should be performed. Cameras, lights, cameraTargets and lightTargets all have a parent. So do objects. When hiarchy is performed all objects will be transformed by the parent transformation matrix. If it has one. Otherways the children pivot/position will be relative to the parent's position-vector. This way lights and cameras can be children to objects, and also objects be children to lights. I also noticed that I had forgot an extra parent-obect for the spotlights (target). Added.
I have also considered doing an .ASC-reader (3d-studio r4) while waiting for more code from Ghyll so I can start doing copying my internal .3DS-structures into the general structures. While doing this (looking in an .ASC I had exported) I discovered something weird about the smoothing-groups. I thought it was weird because I did in an other manner reading .3DS-files. After some digging in all the .3DS-documentations I had I found out why (in Jare's 3ds-reader). I read them completely wrong in my .3DS-reader!
Apparently .3DS has 32 different smoothing-groups. I think that all connected faces in the same smoothing-group should be used when calculating the vertex-normals.
I still do no know about our smoothing-groups though - how they should be like. Calculating vertex-normals from them, whatever they do look like, will be tedious though (it is in the nature of calculating vertex-normals; your engine is never built up to do that, so It is always a mess). I think that vertex-normals thus should be saved in our files.
In the end I decided not to support .ASC-files. They lack most information; they do not even supply where obects are situation in the scene. No nothing. And no keyframing.
Instead I am trying to calculate the correct mapping coordinates for .3DS-files to avoid the famous wrapping-problems. I already extract all the information needed; I have the plane, cylinder or the sphere. All info about them too. Now it is just a matter of calculating. Not very funny to do but atleast I suppose I could give it a try and then compare my values to the mapping-coordinates I already have. They should be similar but not face-bound.
I think that we can not use recursive chunks with our current systems, but I do not know. It is up to Ghyll to say so. Otherwise the BSP-Node-chunk should work by now. I have made two small corrections though.
2000-01-04, 02:47
Ok I have got somewhere to write. Nice.
After a suggestion from Ghyll keyframing was moved to sub-chunks in the objects affected by the tracks (instead of being placed seperatly in a keyframing chunk (as in 3d-studio .3DS, .ASE-files)). This was, of course, annoying to do but now it is done. It will, of course, be far more annoying for Ghyll who has to rewrite the .DTD-file.
Ghyll also send me a class-diagrams (8202x288 .PNG-file =)) which really helped out. Along with XML-files (which gives a nice tree in the browser) it was very easy to find errors in the specification. I really look forward to when we have a stable specification. Saving a test-file should not be far away though. Which leads us to the problem of choosing a good name and an appropriate extension!. Ah.
I must find a neat solution for smoothing groups. Also vertex-normals should be inserted, one way or another. They could rather easily be calculated from the smoothing-groups. Either we provide them or we do a tutorial on how to calculate them. Or both. It should not be that hard.
I have gotten a suggestion about implementing iso-grids (marching-cubes). Left for a later version.
David Larsson reminded me of something I though of in the shower and then forgot completely; two-sided polygons. Either we have two-sided materials or we allow people to store two polygons at the same place facing different directions (different vertex-ordering). That should be supported at the moment, but you need a editor for it too. Converting from a format using two-sided materials should result in two-polygons then. Do not know what to do yet. I have also recieved questions/suggestion about/for the binary-version. Someone wanted compression and I have heard other points-of-views too. I got to find out more about the XML-binary-format first. Do not know if it is any good for our purposes. Otherwise we must set on another. I say chunkbased with numbers like .3DS, but we provide a header-file with all chunknames typedeffed (just as in the specification but with a something before, like the format-extension). But let us look at XML's first.
I got a (in my opinion) good idea today. Many people read the opengl-tutorials at NEHE. Why not make a tutorial on reading 3d-files from this format? Would be nice and will give people a good idea of 3d-formats such as .3DS, .LWS and so on. It would, of course, also lead many people to our website. Well one thing at the time.
