Ok the 3ds loader is loading the model fine, but 3ds doesn’t store normals it stores Smoothing Groups. I say, "Fine I’ve never done these before but I can figure it out". Well it isn’t working out too well When I load my object, it looks like it should (shaded correctly and all), but there’s no material color what so ever, it’s just grey. Gah. I’m sure I enabled the material state. Any guesses just from the problem "My model is grey/white/black in all the right places but doens’t have my material state’s color" what could be wrong? I’m know the material state is enabled. When I turn on WireFrame, the wireframe around my model has the correct material state, and lights correctly. If you feel extreamly sadistic, you can try out TestMaxJmeWrite, it demonstrates the problem. You’ld probably have better luck looking thru the final result (IE the node I attach to rootNode), than tracing thru my spagetti un-finished horibly complex 3ds format code. Here’s the data for my model after 3ds loads it, which is basicly a box. I have a feeling it’s the normals but I just don’t know.
Also, assuming this 3ds file format goes good, what file format should I focus on next? What is most commonly used, or would be most usefull? NWN format? MD3 format? obj format? VRML? X3D? So many to pick.
However I’d suggest .obj for next because it shouldn’t be to hard, is well documented and almost EVERY 3D Modelling App can export it.
Some skeletal animationable format that can be exported by some freeware modellers (eg. blender) would be useful too but i have no idea what that could be.
something that has direct animation and skeletal support.
Milkshape3D is a shareware 3D modeler that does Joint/Skeleton Animations and it only cost like 30$ to buy. A loader for that is already built in.
Some skeletal animationable format that can be exported by some freeware modellers (eg. blender) would be useful too but i have no idea what that could be.
People use blender? I tried it out once and it made my eyes cry.
However I'd suggest .obj for next because it shouldn't be to hard, is well documented and almost EVERY 3D Modelling App can export it.
I was under the impression artist didn't like obj format because it was so incretibly big.
Some skeletal animationable format that can be exported by some freeware modellers (eg. blender) would be useful too but i have no idea what that could be.
People use blender? I tried it out once and it made my eyes cry.
You are basically right it is not easy to use but you should try it again as they did much to the user interface lately and once mastered
( i'm far from that :) ) it is quite powerful and hey, i use linux and it runs on it and is free.
However I'd suggest .obj for next because it shouldn't be to hard, is well documented and almost EVERY 3D Modelling App can export it.
I was under the impression artist didn't like obj format because it was so incretibly big.
Well i don't know about artists but i like .obj as nearly every modeller supports it.
It also has a binary representation ( .mod i think ) and is easy to understand (the polygonal part at least)
But it was a suggestion and every new supported format is welcome.
regards
Martin
This is my opinion on things. So dont take it as what should happen.
I think Jme should be the only model format supported, and the rest shoulkd be taken out of the com.jme.* arch, and should be placed somewhere else, like tools.models.*.
This way, we can focus on adding features to Jme, and if someone would like to change any format to Jme they can do so through that tool.
All other formats could be accessed with this converter then and no other as the .jme loader has to worry about performance, memory consumption and the like.
DP: i assume you try to make this an extensible - converter - frame so one has only to implement a logic - module to add a new format?
Figured I’d chime in, despite being so new to this.
Just curious what the benefit would be to having only one (home grown, I’m guessing?) model format supported? Does it simplify the code? Would there be a noticeable performance improvement? Does it (or can it) have all the features the other ones have?
How difficult would it be to have an abstraction layer (ie, a common interface) that all loaders and/or loaded objects would have to implement (including, and probably based off of, the JME loader)? This could allow for any type of loaded object to work, and would keep the jME code simple as it only has to deal with a single interface. This would also allow developers to create their own loaders for their own formats (I think this is actually how Java3D does things. I’d have to look that up to be sure, though).
I have ZERO clue as to how much work that would be to implement, though. It just sounds like a highly versatile solution.
I’m always cautious when I start thinking: “Bah… I don’t need those things. I can do take care of this better myself.” It often becomes 10x more work than I expected it to be. Sometimes it’s worth it, most of the time it’s not.
That being said… I think putting the loaders for non-jme objects in an outside package might be a good idea. That way, if you don’t need them, you don’t have to include them with your game.
There is an abstract layer, its a class called Model, (ASE, Md2 and MilkshapeASCII extend it). Having said that, the ms3d (binary MilkshapeASCII) doesn’t extend that, neither does our own Jme format ( i dont think ), so in a sense, it hasn’t been taken into account really.
It is true that our home grown format is around 3 - 5 times larger than Md2, but it loads in half the time, it will simply the code. It also can do KeyFrames (which md2 only does) and can do Joint movements (which Milkshape can do). So we do have everthing in one roof. And I think, cep can you confirm this?, that it can save meshes too, e.g. Terrain.
So .Jme isn’t just a model format, its everthing!
The current Jar is around the 500Kb mark, without the models, i think this would decrease to around 400 even to 350. Thats major reason for removing them I think. It would also eliminate having to remeber to use Model when loading md2, ase, milkASCII. And having to use Loader for ms3d, and JmeBinaryLoader to load .jme
isn’t skeletal animation the same as joint animation? :?
And yes, it would be a simple, choose import file, choose type of import file, choose exit filename and location, and click “export”, and that would be it. Fast enough?
isn't skeletal animation the same as joint animation?
Yes, I think so. After all skelton is made from a series of joints connected together.
And yes, it would be a simple, choose import file, choose type of import file, choose exit filename and location, and click "export", and that would be it. Fast enough?
That would be great. Which tool and format do you have in mind as I am keen to use it in JME :?
tomcat
I haven’t started yet as I am waiting confirmation from mojo/renanse to get the go ahead. Its a big decision and there are alot of pros/conns in the design.
The tool will support all current model formats, that includes MilkASCII, ms3d, md2, ASE, and JmeXML.
Definitely something for Mojo. In the past, he’s supported having a JME model format that we can optimize for.
Keep in mind though that there’s also nothing stopping us from letting additional model formats be supported via additional libs. For example, in “Dirt” (title of a game my friend and I are working on) we are using NeverWinter Nights models. Our loader code is seperated and packed as it’s own standalone jar. The NWNModel extends Model, the NWNAnimationController extends Controller, etc… As long as we don’t shut out this route as a possibility, I’m for it.
oh definetly not. Its just a way for cleaning the library. Because:
if your using Md2, ASE, MilkshapeASCII, you want to do this:
Model mo = new Md2Model("name"); // or equivilant
if your using ms3d
Loader lod = new Loader(…);
if your using Jme binary:
JmeBinaryLoader jbl = new JmeBinaryLoader();
which seem a bit much and the interface is unclean. By only allowing Jme to be loaded, and other can be changed to Jme, it cleans that mess (lack of a better word) up.
jME will only support one file format. This file format must be human readable. That one format is jME format. This one format will be optimized as much as posible, but will be the only format jME supports
Other formats like md2 and ms3d and ase and 3ds and obj ect ect must be converted to jME format. jME will include libraries to convert from md2 or others to the jME format. People will distribute the jME model with their game, not an md2 or ms3d.
jME format is easy to convert to because it is human readable, so if someone wants to support a future file format they don’t -have- to process that complex file and load it into jME the right way and hope that it’s fast enough, they can just convert it to XML which is easy as pie. jME binary is the binary equivalent of the XML code (IE they are 1 to 1). It is still human readable because it can be converted to and from XML.
jME binary is loaded very quickly because it is basicly a binary representation of the class. All the other loaders you see are legacy from the old loading system and will be removed once this format is completely tested, and a release happens
Short story: jME only loads jME binary. Other formats must be converted to jME binary to be loaded. If a user wants to, the format can be converted to XML first and there is a library already written that will convert XML to binary
Advantages: jME binary loads extreamly fast. jME binary will be completely tested. Users can easily write tools to convert whatever modeler they are using to export XML which can be interpreted by jME and loaded.
When I load my object, it looks like it should (shaded correctly and all), but there’s no material color what so ever, it’s just grey. Gah. I’m sure I enabled the material state. Any guesses just from the problem "My model is grey/white/black in all the right places but doens’t have my material state’s color" what could be wrong? I’m know the material state is enabled. When I turn on WireFrame, the wireframe around my model has the correct material state, and lights correctly. If you feel extreamly sadistic, you can try out TestMaxJmeWrite, it demonstrates the problem. You’ld probably have better luck looking thru the final result (IE the node I attach to rootNode), than tracing thru my spagetti un-finished horibly complex 3ds format code. Here’s the data for my model after 3ds loads it, which is basicly a box. I have a feeling it’s the normals but I just don’t know.
(sorry i’m no native speaker)