Load WaveFront OBJ maps composed of quads (for TUER JOGL-based beta version)

Hi



I find this code to load an OBJ model on the wiki:


ObjToJme converter = new ObjToJme();
try {
URL objFile = TestObjJmeWrite.class.getClassLoader().getResource(
"your_model_name.obj");
converter.setProperty("mtllib", objFile);
                        converter.setProperty("texdir",objFile);
ByteArrayOutputStream BO = new ByteArrayOutputStream();
System.out.println("Starting to convert .obj to .jme");
converter.convert(objFile.openStream(), BO);
                        //load as a TriMesh if single object
TriMesh model = (TriMesh) BinaryImporter.getInstance().load(
new ByteArrayInputStream(BO.toByteArray()));
                        //load as a node if multiple objects
                        //Node model=(Node)BinaryImporter.getInstance().load(
                        //                new ByteArrayInputStream(BO.toByteArray()));
model.setModelBound(new BoundingSphere());
model.updateModelBound();
rootNode.attachChild(model);

} catch (IOException e) {
e.printStackTrace();
}


As my OBJ file contains only quads instead of triangles, can I use QuadMesh instead of TriMesh?
If I load the OBJ file as nodes, will it work fine even though it contains quads?
How does the importer fill the list of children of the nodes? Does it put the whole OBJ model into a single node?
Does JME support cycles? Imagine a node has 6 children, one of them has 2 children and one of these children has the very first node as a child. I ask this question because TUER handles forests of graphs by default, I want to know if I have to change this behavior for JME 2.0. Thank you very much for reading. Sorry if my questions are stupid, I'm a newbie in JME  :D

the importer can return a TriMesh or a Node, it depends on the .obj File.

Because of that its best to cast it to a Spatial instead of a Node or TriMesh.


Imagine a node has 6 children, one of them has 2 children and one of these children has the very first node as a child

Is this not a endless Loop ?

A Node can only have one Parent, so when you attach that the first Node to another Root Node (to attach it to a scene), it will break the cycle.
Core-Dump said:

the importer can return a TriMesh or a Node, it depends on the .obj File.
Because of that its best to cast it to a Spatial instead of a Node or TriMesh.

Ok but I don't understand this:
Problem: mesh is incomplete or has holes in it in JME.

Model must be made of triangles

This comes from the wiki: http://www.jmonkeyengine.com/wiki/doku.php?id=exporting_.obj_models_from_blender
I have spent several weeks to write a program to convert my map from the native format of my engine to the WaveFront OBJ format. My map is only composed of quads and TriMesh instances are composed of triangles, aren't they?

Imagine a node has 6 children, one of them has 2 children and one of these children has the very first node as a child
Is this not a endless Loop ?
A Node can only have one Parent, so when you attach that the first Node to another Root Node (to attach it to a scene), it will break the cycle.

This doesn't lead to an unless loop in my own engine because I implemented the Breadth First Search and the Depth First Search with a marking system to avoid visiting twice the same cell but if I understand what you wrote, JME does not support it yet.

Thank you very much for your quick reply.

A node can ONLY ever have one parent, in the setParent() method it will be set to a singular parent (wether the new parent is null or not)…


the importer can return a TriMesh or a Node, it depends on the .obj File.
Because of that its best to cast it to a Spatial instead of a Node or TriMesh.


TriMesh -> Extends Spatial - is actually geometry
Node    -> Extends Spatial - is a 'logical' holder for TriMeshes
So when a model is loaded and it has only ONE mesh it is returned as a TriMesh, if there is more than one mesh it is returned as a Node.


My map is only composed of quads and TriMesh instances are composed of triangles, aren't they?

Yes, and ONLY triangles are supported in jME (no quads, even though they are supported by openGL).  You will need to implement an algorithm that goes through each quad and breaks it into 2 triangles (easier than it sounds actually, face winding is the biggest gotcha...)

jME does support quad meshes but it's quite limited. For example, you can't do triangle-collision on them.

Some OBJ exporters can triangulate your mesh, also, you may be able to convert the mesh into a triangle mesh inside the modeling tool.

jME does support quad meshes

hmm, I didn't know that....

http://code.google.com/p/jmonkeyengine/source/browse/trunk/src/com/jme/scene/QuadMesh.java



But, as I mentioned, using it is not recommended. Many jME utility and other classes are only designed to operate on triangle meshes, so using QuadMesh is guaranteed to bring forth some very unexpected issues.

I imagine it would not be too hard to write some JME quad to trimesh code. That might be a useful addition.

Momoko_Fan said:

jME does support quad meshes but it's quite limited. For example, you can't do triangle-collision on them.
Some OBJ exporters can triangulate your mesh, also, you may be able to convert the mesh into a triangle mesh inside the modeling tool.

Ok, then I will modify my own exporter to write faces as triangles rather than quads :( (it is simple but I have already spent lots of time on this part) I thought JME 2.0 was more robust that this. Thank you for the advices, it will prevent me from making some big mistakes.

Nevertheless, when I tried to use triangles rather than quads in my own engine, the frame rate decreased :( Why? Because then the VBOs were bigger. This means that I might get worse frame rate with JME than with my own engine  :cry:

If there are several objects in a single OBJ file, the importer will put them into a single node but this node will contain several TriMesh instances, won't it? Is it possible to import a single OBJ file so that each object ( "o objname" in the OBJ file) is in a node? According to you, is it complicated to modify the behavior of the class Node to allow a node to have several parents?
I thought JME 2.0 was more robust that this

Umm, the point of only using triangles IS too make jME as robust as possible (this way there is a common format, and the physics engine doesn't have to worry about testing for quads for example). 
Furthermore, it nicely solves the potential problem of four vertices not being on one plane (which would be a concave polygon, and that could be a nightmare to debug).

I don't think many game engines support quads as a first class geometry format. Also consider that they are much slower to draw even if supported because the video card converts them to triangles on-the-fly.

Momoko_Fan said:

I don't think many game engines support quads as a first class geometry format. Also consider that they are much slower to draw even if supported because the video card converts them to triangles on-the-fly.

I think you're right but personally, my graphics card go faster with a VBO composed of quads than the same VBO but with only triangles.

basixs said:

I thought JME 2.0 was more robust that this

Umm, the point of only using triangles IS too make jME as robust as possible (this way there is a common format, and the physics engine doesn't have to worry about testing for quads for example). 
Furthermore, it nicely solves the potential problem of four vertices not being on one plane (which would be a concave polygon, and that could be a nightmare to debug).

But we could at least find a solution to convert quads into triangles during the importation, couldn't we?

:smiley: It works :







Now, I’m going to try to load this in JMonkeyEngine 2.0, I’m a bit worried.