Vertex colours in Azathoth

[AshSid]

I'm a newbie and have problem with displaying model's vertex colours in OGRE 1.0.0RC1. Model is shaded and has texture, but no vertex colours. The same model works just fine with 0.15.2.

Is it a bug in Azathoth or I need to set up something to make it work.

Thanks for your answers.

[:wumpus:]

you need to add one or more of the following to your material to actually use the vertex colour in a lighted model:

diffuse vertexcolour
specular vertexcolour
ambient vertexcolour
emissive vertexcolour

[sinbad]

Please read the porting notes if you're upgrading, it really is all in there and we didn't write it for fun

[AshSid]

Thanks for your suggestions, I will dig deep back into the documentation.

[AshSid]

I have another question: vertex colours in OpenGL look like they have swapped blue and red component (red vertices are blue and blue vertices are red). I have tested the same mesh in sample applications (skeletal animation) and looked the same way.

Do you have any suggestion on this?

[DWORD]

You need to use Ogre::Root::convertColourValue().

[AshSid]

Fine, but I think it should convert colour values during mesh loading. All I do is a call to Ogre::SceneManager::createEntity(name, mesh). So I should convert colour values after creating the entity?

[DWORD]

Fine, but I think it should convert colour values during mesh loading. All I do is a call to Ogre::SceneManager::createEntity(name, mesh). So I should convert colour values after creating the entity?

Ah sorry, thought you were writing the colours yourself. No I don't think it should be necessary to convert the vertex colours manually. I thought the MeshSerializer would take care of the conversion, maybe there's an issue with vertex colours stored in .mesh'es?

[AshSid]

As far as I can tell, vertex colours in mesh files are correct. I have checked mesh.xml file, and vertex colours are in RGBA order (for example: <colour_diffuse value="0.898039 0.698039 0.000000 1.000000"/> is kind of yellow).
When I set Direct3D for rendering, colours are correct, when I choose OpenGL, it looks like red and blue are swapped. Textures are correct in both Direct3D and OpenGL.
The first image is from direct3D, the second is from OpenGL.

[DWORD]

As far as I can tell, vertex colours in mesh files are correct. I have checked mesh.xml file, and vertex colours are in RGBA order (for example: <colour_diffuse value="0.898039 0.698039 0.000000 1.000000"/> is kind of yellow).
When I set Direct3D for rendering, colours are correct, when I choose OpenGL, it looks like red and blue are swapped. Textures are correct in both Direct3D and OpenGL.

The mesh is exported correctly (provided RGBA is the standard for colours in .mesh), the problem arises on import into Ogre, because the different render systems treat the colour values differently. I.e. the RGBA values stored in the .mesh is in D3D's native format, while GL expects BGRA values.

If you look into MeshSerializerImpl_v1_2::readGeometryColours() you see there's no conversion of the colour values depending on the render system. I don't think the MeshSerializer is aware of which render system is in use, but maybe the render system should be considered when importing .mesh'es?

Nice model btw.

[dennis]

If you look into MeshSerializerImpl_v1_2::readGeometryColours() you see there's no conversion of the colour values depending on the render system. I don't think the MeshSerializer is aware of which render system is in use, but maybe the render system should be considered when importing .mesh'es?

Nice model btw.

Hell yes! But ... it's the first time I've seen this particular difference in DirectX and OpenGL. Is the part where the colours differ untextured? Is it a bug in the vertexcolor or in the material definition?

[DWORD]

Hell yes! But ... it's the first time I've seen this particular difference in DirectX and OpenGL. Is the part where the colours differ untextured? Is it a bug in the vertexcolor or in the material definition?

This difference applies only to vertex colours, as textures are handled much more thoroughly with pixel formats etc. I think the reason this 'bug' hasn't been discovered before is because very few people ever used vertex colours stored in .mesh-files. You'll see the difference also if you manually fill vertex colours into a vertex buffer. There you have to use Ogre::Root::convertColourValue() as I wrote earlier to ensure compatibility with different render systems. So this is neither a bug in the .mesh vertex colours nor in the material definition, but a missing conversion on import into Ogre.

I don't know how this should be fixed, though, because I think either the MeshSerializer needs to be aware of the render system, and this is a complication which is not needed in most situations. Or some post processing of vertex colours are needed after the mesh has been loaded.

Edit: Maybe it isn't that complicated. If we can be sure there's always an active render system upon mesh import, then we can convert using Ogre::Root::convertColourValue(). There's no need to pass the render system to the serializer.

[AshSid]

DWORD, thanks for your explanation. If I try add colour conversion to MeshSerializerImpl_v1_2::readGeometryColours() using Root::convertColourValue(), I think it will not make MeshSerializer dependent on render system, because conversion will be always performed.

Or, maybe I should do nothing. This model is just for testing purposes, and real models will be fully textured. So maybe I can forget it at all.

[DWORD]

DWORD, thanks for your explanation. If I try add colour conversion to MeshSerializerImpl_v1_2::readGeometryColours() using Root::convertColourValue(), I think it will not make MeshSerializer dependent on render system, because conversion will be always performed.

It would still depend indirectly on the render system, because Root asks the active render system to do the conversion, but if you only import geometry when there's an active render system there's no problem.

Edit: Coming to think of it, as it's possible to export from inside Ogre, the export should also take into account the render system. Maybe we need some functions converting between render system specific vertex colours and those in the .mesh (RGBA?). But where to put these functions? In the RenderSystem or maybe even in the HardwareVertexBuffer? The latter is maybe hacky, but then we could take advantage of the DefaultHardwareVertexBuffer not requiring a render system.

[sinbad]

Argh, this is on my list of pet peeves. After months of research (elapsed ) it appears there is no way to make GL understand D3D vertex colours or vice versa. So in terms of the .mesh format, I either need to:

- pick one, making the other rendersystem convert
- pick another format that both have to convert
- store both versions, making loading faster but files bigger

My preference is the last one, but I haven't had time to implement it yet. Thoughts?

[AshSid]

sinbad,

would it be possible to allow more than one implementation of .mesh file loader? .mesh file should contain flag, which will tell it wants to convert vertex colours or already has converted version of them. That would allow fast loading, where it's needed, and small files, where it is not.

DWORD,

in fact, mesh loads using MeshSerializerImpl::readGeometryVertexBuffer(), so changes in MeshSerializerImpl_v1_2::readGeometryColours() dont work.

[DWORD]

Argh, this is on my list of pet peeves. After months of research (elapsed ) it appears there is no way to make GL understand D3D vertex colours or vice versa. So in terms of the .mesh format, I either need to:

- pick one, making the other rendersystem convert
- pick another format that both have to convert
- store both versions, making loading faster but files bigger

My preference is the last one, but I haven't had time to implement it yet. Thoughts?

I didn't even think of changing the render systems' interpretation, it's a pity that isn't possible. I think the choice is between no. 1 and 3, as 2 would cause slowdown in both render systems. 3 is no doubt the fastest solution, but will it be compatible with the current .mesh format? I guess the conversion time in 1 is negligible, but which rendersystem system would be 'native' then? 3 is probably the best long term solution, it doesn't really take up that much space, and it's fastest to have the data preprocessed.

DWORD,

in fact, mesh loads using MeshSerializerImpl::readGeometryVertexBuffer(), so changes in MeshSerializerImpl_v1_2::readGeometryColours() dont work.

Heh, I see. That's what I get for writing before testing. What's readGeometryColours() doing there then, just sitting around deluding people?

[Bill]

- pick one, making the other rendersystem convert
- pick another format that both have to convert
- store both versions, making loading faster but files bigger

My preference is the last one, but I haven't had time to implement it yet. Thoughts?

How about #1 where the user picks which type is "native."

eg:
<vertexbuffer.... vertex_colour_type="OpenGL" colours_diffues="true" ...>

or maybe

<vertexbuffer.... vertex_colour_order="RGBA" colours_diffues="true" ...>

That way the user can pick which one will be optomized. If loaded up in a different system then the different system would do the conversion.

[sinbad]

@Bill: yeah, that's actually what I meant by 'pick one', otherwise I'd be accused of preferring one rendersystem over the other (and be lynched by one group or another ). However I don't like target-specific assets which is why I opted for #3. It wouldn't make the file that much bigger (in binary form). I'd planned on changing the XML so it's floating point r/g/b based instead too.

This is one for Dagon.

[:wumpus:]

My preference is the last one as well; user should not have to pick a 'preference' between rendersystems, Ogre should be transparent. Colours are only four bytes anyway (in the binary format).

In the XML please only store one The swizzling uses so little time compared to the parsing that it doesn't matter.

[sinbad]

In the XML please only store one The swizzling uses so little time compared to the parsing that it doesn't matter.

Of course! That's why I said float r/g/b ie the original ColourValue stylee which is rendersystem independent.