Hi !
Featured games (90)
games approved by the League of Dukes
Games in Showcase (701)
Games in Android Showcase (203)
games submitted by our members
Games in WIP (774)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  File Loading - Which is the quickest format ?  (Read 2701 times)
0 Members and 1 Guest are viewing this topic.
Offline Makaveli

Junior Newbie

Java games rock!

« Posted 2002-10-27 14:44:53 »

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 ?


Offline Orangy Tang

JGO Kernel

Medals: 57
Projects: 11

Monkey for a head

« Reply #1 - Posted 2002-10-27 15:15:27 »

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  :-/

[ - Play Growth Spurt, Rescue Squad and Snowman Village ] [ Rebirth - game resource library ]
Offline Makaveli

Junior Newbie

Java games rock!

« Reply #2 - Posted 2002-10-27 15:19:00 »

Thanks very much.
Sounds like a good idea to me.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Herkules

Senior Devvie

Friendly fire isn't friendly!

« Reply #3 - Posted 2002-10-28 10:56:19 »


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.

- J

HARDCODE    --     DRTS/FlyingGuns/JPilot/JXInput  --    skype me: joerg.plewe
Online Spasi
« Reply #4 - Posted 2002-10-28 14:07:12 »

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... Wink
Offline Herkules

Senior Devvie

Friendly fire isn't friendly!

« Reply #5 - Posted 2002-10-28 14:57:33 »


AFAIK, scenegraph objects do not implement Serializable, so this cannot work.

But meanwhile, there is scenegraph I/O (

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?

HARDCODE    --     DRTS/FlyingGuns/JPilot/JXInput  --    skype me: joerg.plewe
Offline Jeff

JGO Coder

Got any cats?

« Reply #6 - Posted 2002-10-28 16:00:08 »

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).  

Got a question about Java and game programming?  Just new to the Java Game Development Community?  Try my FAQ.  Its likely you'll learn something!
Online Spasi
« Reply #7 - Posted 2002-10-28 19:55:08 »

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?
Offline Herkules

Senior Devvie

Friendly fire isn't friendly!

« Reply #8 - Posted 2002-10-29 06:32:03 »


All you need to do then is load the data in memory and THEN create the proper scenegraph objects.

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 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.

HARDCODE    --     DRTS/FlyingGuns/JPilot/JXInput  --    skype me: joerg.plewe
Offline Conzar

Junior Devvie

There is nothing common about common sense

« Reply #9 - Posted 2002-11-20 16:18:33 »

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.?

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline gregorypierce

Senior Devvie

I come upon thee like the blue screen of death....

« Reply #10 - Posted 2002-12-17 02:17:28 »

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.

She builds, she builds oh man
When she links, she links I go crazy
Cause she looks like good code but she's really a hack
I think I'll run upstairs and grab a snack!
Pages: [1]
  ignore  |  Print  
You cannot reply to this message, because it is very, very old.

ral0r2 (191 views)
2016-11-23 16:08:26

ClaasJG (331 views)
2016-11-10 17:36:32

CoffeeChemist (424 views)
2016-11-05 00:46:53

jay4842 (476 views)
2016-11-01 19:04:52

theagentd (487 views)
2016-10-24 17:51:53

theagentd (475 views)
2016-10-24 17:50:08

theagentd (433 views)
2016-10-24 17:43:15

CommanderKeith (431 views)
2016-10-22 15:22:05

Roquen (403 views)
2016-10-22 01:57:43

Roquen (302 views)
2016-10-17 12:09:13
List of Learning Resources
by elect
2016-09-09 09:47:55

List of Learning Resources
by elect
2016-09-08 09:47:20

List of Learning Resources
by elect
2016-09-08 09:46:51

List of Learning Resources
by elect
2016-09-08 09:46:27

List of Learning Resources
by elect
2016-09-08 09:45:41

List of Learning Resources
by elect
2016-09-08 08:39:20

List of Learning Resources
by elect
2016-09-08 08:38:19

Rendering resources
by Roquen
2016-08-08 05:55:21 is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!