Hi everyone.
I have about 250 objects to load into my game, all of which I currently have in .OBJ format. This takes a freakin’ age to load up as I’m sure you can imagine.
Any idea if any other format (HAnim, DXF, etc) will be quicker to import ?
Thanks
Mak
You could do as I do and create your own file format that only contains the bare information that you need - Cas’ image converting gave me the idea, its pretty much the same thing.
I use Milkshape .ms3d files and run them though my little converter app to write my .mesh files. Its quite neat since i can strip out all the bone animation that i won’t be using and do some pretty heavy vertex merging/re-indexing before producing the final file. At some point I may add tri strip generation but thats definatly not trivial…
I’d recommend you stay clear of .DXF though, the file types seem to be much larger than the equivilent milkshape models that i’ve seen. Dunno about other formats though :-/
Thanks very much.
Sounds like a good idea to me.
Yes, good idea. But also sound like a lot of work to me!
You have to be able to parse one format and write another. Then you have to get your models to the one format (tried to read 3ds-models into milkshape?).
I once wrote a MAX-ASE parser, which can be a very annoying task!
So a hint on the best method to load 3D data would be still great.
I found that starfires 3DS loader works good and 3DS is quite compact (not an ASCII format).
Never tried famous OpenFlight loader, for it’s rather difficult to find models in that format.
What about the Java3D owns format? Is it quick? Are there conversion tools?
I’d really love to hear what experiences people out there made with Java3D loaders.
Just a thought…
Why not load your model into J3D with whatever loader you’ve got, perform any optimizations or anything you want on it, then just export/serialize it to disk as a standard Java object? Just build a program that does only this. Then through your game engine just deserialize it and use it as needed. This way all you have to think about is standard (simple/easy) Java IO.
You can even compress it after serialization… 
[true_knowlegde=off]
AFAIK, scenegraph objects do not implement Serializable, so this cannot work.
But meanwhile, there is scenegraph I/O (com.sun.j3d.utils.scenegraph.io).
Any1 has experience with that format? Are there authoring tools that directly support *.j3d?
I know there is a nice plugin for NetBeans - how far can I get with it?
Okay some basic file rules:
(1) The MOSt expensive thing in msot practicla cases is asking the file system to open a file. Thsi is why msot games use a “bigfile” system where al l the info for a level is in a single file.
(2) After that, and after you’ve eliminated anby large and unecessary data, it becomes a trade off. if you have a very fast processor then itys worth minimizing the data flow off disk with a very comrepssed format. If you either have a very slow processor or very fast Io though, the reverse may be true.
In the past, the tardeoff has often been to use very simple compression schemes that are easy to decode (eg RLE).
Herkules wrote : "AFAIK, scenegraph objects do not implement Serializable, so this cannot work. "
Herkules, I wan’t referring to a scenegraph object, but to a custom object that just holds the necessary arrays that were imported from the loader. And of course whatever other data necessary.
Then you can serialize/deserialize this object as needed. Or build your own custom “bigfile” system to avoid opening many files, as Jeff suggested.
All you need to do then is load the data in memory and THEN create the proper scenegraph objects.
I hope I make sense. What do you guys think about such a technique? I haven’t tested it yet, but I plan to when I have some time available. Is it worth testing?
I have the feeling that this just creates another intermediate description of scenegraph content that better should be the scenegraph itself…
One point might be to keep the content construction pipeline as short and easy as possible. This means to avoid custom content compilers (‘bigfile’) if possible.
I agree that most larger game projects cannot do without some steps in the content creation pipeline due to some specific needs in the data (BSP,…) that common modellers cannot provide.
So, the Java3D Loader interface or the package com.sun.j3d.utils.scenegraph.io offer good possibilities to shortcut content load.
The question here is which of the common formats/loaders are best suited to setup a simple content pipeline.
Does anyone have experiance with .wrl (VRML) files? I still don’t think Mak’s question has been answered. Besides making your own special format, what is the best file format that is currently available w/out any implementation? Also - what are the comparisons between the differnt file format, eg
J3D, VRML, MAX, ect.?
I’ll throw in my 2 cents. First ask yourself if you really need to load all 250 objects all at once. If you do, its just going to take a while if you have to open and close a file handle for each one. I would personally recommend coming up with your own format that can be memory mapped using JDK1.4 so that you can blitz through the file (and its surprisingly easy to implements).
If you don’t need all the objects all at once I would suggest writing a lazy loader that has cache validation and loads objects as they are needed or as the system has time in the background. Nothing is more annoying than waiting 10+ minutes for a level to load. Reminds me of WingCommanderIII where levels would literally take 20+ minutes to load on the average machine. What I’ve done in this regard is modelled off J2EE caching systems. I know what I need, and I put triggers in my scene so that I can start the loading of other things into the cache. If your code asks the cache for an object that’s not currently available I grab it out of my memory mapped file, and its very fast to do that as opposed to loading an entirely new object from disk (evil). Objects that have lots of cache hits sit in memory longer than objects that don’t. To aid this, I gather heuristic data about the scenes I’m constructing so I can load the necessary objects first and at least get the scene rendering and bring in lods of other objects so the game can keep moving as opposed to choking on trying to bring in a 12k polygon model when it only takes up 10 pixels on the screen way off in the distance.