Sadly not all of those editors works under linux . Anyway, it's just more fun.
Regarding "phong", maybe i'm missing some feature of the Lighting material but I don't see how to set the parameters of phong (collada phong) using it. the phong parameters are:
DAENode emission = phong.getChild(Names.EMISSION); //color or texture
DAENode ambient = phong.getChild(Names.AMBIENT); //color or texture
DAENode diffuse = phong.getChild(Names.DIFFUSE); //color or texture
DAENode specular = phong.getChild(Names.SPECULAR); //color or texture
DAENode shininess = phong.getChild(Names.SHININESS); //float or param
DAENode reflective = phong.getChild(Names.REFLECTIVE); //color or texture
DAENode reflectivity = phong.getChild(Names.REFLECTIVITY); //float or param
DAENode transparent = phong.getChild(Names.TRANSPARENT); //color or texture
DAENode transparency = phong.getChild(Names.TRANSPARENCY); //float or param
DAENode indexOfRefraction = phong.getChild(Names.INDEX_OF_REFRACTION); //float or param
I can use m_DiffuseMap for the texture in the diffuse element. I can use m_Ambient, m_Diffuse and m_Specular for the ambient, diffuse and specular colors. One of the jme3 tests shows that lighting supports transparency so i can use that for the trapsnarecyFloat value. I have the m_Shininess, i think i can use m_SpecularMap for specular but I can't see the rest.
I have a "missing" problem for lights too. In JME3 i have point and directional, in collada the basic lights are the know ones (spot, ambient, point, directional) but with a lot of parameters. I thought i could try to "build" those lights with shaders.
We can't expect to support every single feature of the format, that will just be a lot of work. The reflection/refraction part of a Collada shader for example probably won't be supported as it requires special post-processing filtering to support it.
Most of the features should already be there, for example, the following are already supported:
ambientColor
diffuseColor
specularColor
shininessFloat
diffuseTexture
specularTexture
One thing I notice missing is normal maps. Does collada support normal maps? It most definitely should… Otherwise it is kind of useless as a game model format.
One of the cool thing of COLLADA is that the format can describe pretty everything, from fixed function pipeline style materials to embedded pixel shader source code, from physics to animations. Its remarkably generic. I could say that if it is displayable than you can describe it with collada.
Collada geometries are defined as indices set relative to buffers. The problem is that there is one index buffer for vertex component. So i have:
vertex index buffer -> vertex buffer
normal index buffer -> normal buffer
texture coordinate index buffer -> texture coordinate buffer
and so on. In JME3 I have (if i'm not wrong) one index buffer and several data buffers, interpreted relatively to the unique index buffer. I'm I correct?
While we're talking about geometries… collada geometries can be defined with polygons so, sooner or later, i'll need a triangulator. Initially i was tempted by the FIST triangulator used in Java3D utils but it is not freely translatable. The polygons used by collada are non planar, convex, concave, self intersecting, with holes, specified by apparently unordered lists of vertices.
Does anyone know of a free (beer and speech) algorithm suited for this scenario?
i have temporarily raised my hands on materials, i’ve bult the skeleton for phong/lambert and forwarded everything to Lighting. Transform test looks ok, dice has weird halos due to lighting but color and texture is ok.
I have a weird issue with rights wheels where triangles’ faces are reversed, still don’t know why, i have to check.
There is also a character in the original file, it is not displayed because it is put in place with skinning or something like that, not yet implemented.
As a side note, the jme3 plug-in can load the file while the blender one don’t. AH!
While we're talking about geometries... collada geometries can be defined with polygons so, sooner or later, i'll need a triangulator. Initially i was tempted by the FIST triangulator used in Java3D utils but it is not freely translatable. The polygons used by collada are non planar, convex, concave, self intersecting, with holes, specified by apparently unordered lists of vertices.
Does anyone know of a free (beer and speech) algorithm suited for this scenario?
There's GTS.. I'm not sure if it will do triangle conversions but I know it does subdivisions (and wouldn't be surprised if it could do what you needed).. The downside is that its in C
That gts looks interesting, thanks. One day i'll try to make a port.
The missing triangles in moon buggy were due to back face culling. Looks like the model requires to turn it off. Once done, everything looks fine (including the sky dome).
The model also requires multiple texcoords sets and ambient occlusion. The screenshot doesn't display that because the shader i've written for phong is really shadeless (in fact it is the same i use for lambert and the same i will use for blinn).
If there's a particular feature that you think is needed, I can implement it in the jME3 standard lighting material (Common/MatDefs/Light/Lighting.j3md) so that you don't have to make your own.
Blinn and Phong are very similar materials, so I don't think it's really necessary to implement them differently. You can reproduce one with the other by increasing/decreasing shininess by a certain amount.
The offer is greatly appreciated but before to start polluting JME3 with collada specific features i would like to implement at minimum the animations and physics data, otherwise the plug-in itself would be of little use.
I'm generating the skeleton and I have to associate mesh vertices to bones. I can't find the jme3 way to do it but i know that it lies somewhere. Where is it? Thanks.
or setting a user transform before the binding pose can cause problems?
Btw, i still have to solve the puzzle: vertex indexing. Collada animates geometries which is fine but i have multiple meshes for each collada geometry (and none of them preserves the original indexing :D).
I don't see why you would want to use the user transform though, that one is only for direction manipulation of the bone by the user, its not used for animation.
I have a skinned mesh with no animation, just a "static" pose, i saw these setters and i thought "hey, this is what i need!". I was wrong :D.
Btw, i'm rewriting mesh parsing. The old way was wonderfully easy but didn't work very well with skinning. I still have some doubt about the "one mesh per material" stuff.
If i have a cube and i apply a material to each face the collada file results in one geometry with 4 faces linked to four material. The jme scene has one node and four geometries. With skinning this could cause some headache.
If i have a cube and i apply a material to each face the collada file results in one geometry with 4 faces linked to four material. The jme scene has one node and four geometries. With skinning this could cause some headache.
How is this a headache? Thats the only way to do it.