Java Universal Model Importer (JUMI) - Early Alpha

Engines, Libraries and Tools
#21

By the point of view of supported formats you are right, but there is much more behind that.

I wrote most of the validation stuff, to check that the loaded data are valid

I am writing now some post-processes

All of this applies to the data loaded under the Assimp structure (aiNode, aiScene, etc), the supported formats are just the pure importers that reads the data in that format

Once I finish porting most of the core, supporting different formats should be relatively easy as porting just one C file code

#22

I’d like to improve the AiMaterialProperty I wrote on the fly the first time…

if you could take a look at it and give me some hints it’d be great <3

#23

The most I can do for you now it’s to upvote your S/O question :slight_smile:

#24

Has this been worked on at all? :slight_smile:
Very interesting idea!

#25

I am working on the post-processing part

#26

I have implemented something similar into my game development program and it just auto converts everything to OBJ models… but i only support very few model types at the minute as it is a pain to learn the data structure behing the formats ;D

#27

If only we had someone working on a sound library like this.

#28

What’s wrong with paulscode?

#29

License

#30

[quote]You are free to use this library for any purpose, commercial or otherwise
[/quote]
What’s wrong with that license?

#31

For info: i am updating the tutorials, because this started from the oglDev tutorial, as soon as I am done I will go on with jAssimp.

But if anyone can help, don’t hesitate please

#32

Is this still being worked on?

#33

I am not done yet with the tutorial update.

In the meanwhile I am also trying to solve a vs15 compiling error…

Which format do you need btw?

#34

Any format that stores animation data. FBX, MD5, whatever. It seems JUMI doesn’t store the animation duration and the animation channels.

#35

Would you be available to start coding one of those in the meanwhile?

#36

Hm…I’ll have to see about that. I’m still new to skeletal animation and I still haven’t figured out the FBX file format.

#37

I can’t really contribute to model loading and animations, as you guys surely know more about it than I do. I haven’t been around any model format except OBJ and I still cut the crap out of it just to the model’s verts, norms, and texcoords.

I like the idea of JUMI, but I got a little confused on the way skimming over comments and the general idea. Will JUMI actually store the model data or be a loader which gives you the data asked for? In the case of JUMI loading the data and keeping it, who knows what memory retention that would cause in the VM. I would like something that loads things into a class which I can then allot the data and discard as need be. I don’t want to reference JUMI to deref it.

Another thing I wanted to ask was… is there one specific model data format container? Like… fit OBJ and MD5 data into say… ModelData.class? Or will it be seperated out into OBJModelData.class?

#38

I’ve started work on an MD5 model loader :smiley:

#39

To answer your question, yes, JUMI does store the model data in the JUMIMesh class. Assimp, the most popular model loader, does this as well. Don’t sweat it, you won’t face any issues with the memory, unless your models are incredibly detailed and have millions of polygons (which probably isn’t the case).

And no, there isn’t a class for every file format. MD5, OBJ, FBX…all of the data is stored in JUMIMesh, regardless of the file format.

#40

I think that last part is a big issue. There should be a copious amount of polymorphism. This allows me to box and unbox.
It would save on the millions of booleans created, too. isWhateverSupported()

I am afraid you didn’t answer my question. When you are saying the data will be stored in the JUMIMesh class, does it get returned or is it stored inside of the JUMI library to be flushed out?