![[de]](/mwf/flags/de.png "Germany")
Hi. Are the meshes (and materialscripts....) the same used by ogre? I hope someone can answer this.
Yes, should be
Thanks for the quick answer. That should mean that i can use my blender -> ogremesh exporter for creating OC graphics. :)
![[ca]](/mwf/flags/ca.png "Canada")
Yes, but they only support a fraction of what OGRE uses. For example, we only use Diffuse lighting. If you take a look at some of the material scripts, you'll see how simplistic they are.
![[gb]](/mwf/flags/gb.png "United Kingdom")
Well, hopefully the lights stuff will give us directional light eventually. That would be the "diffuse" part, right?
And hm. Ogre seems to have some sort of shader support itself. Would it be useful to support that?
And hm. Ogre seems to have some sort of shader support itself. Would it be useful to support that?
Meshes are rendered with a simple directional light so far.
The Shader support of Ogre would certainly be useful to support (bumpmaps!), but we'd have to figure out how to connect it to the other features that are supposed to work with C4Objects (such as FoW (will be covered by your lights work?), ClrModulation/MOD2, maybe other things I forgot (blending/face ordering?)). I suppose those would need to be made available to the shader and then we rely on it doing the correct thing.
The Shader support of Ogre would certainly be useful to support (bumpmaps!), but we'd have to figure out how to connect it to the other features that are supposed to work with C4Objects (such as FoW (will be covered by your lights work?), ClrModulation/MOD2, maybe other things I forgot (blending/face ordering?)). I suppose those would need to be made available to the shader and then we rely on it doing the correct thing.
I'm still really struggling with getting the big picture here. The ogre format seems to encode the rendering pipeline to a significant degree, if I read that correctly. Now does that mean that...
* I could theoretically leave the mesh rendering code as-is and depend on the meshes to all have shaders attached to them? If I read the specs correctly, they could just "include" a standard shader when in doubt.
* Would this allow you to still get a useful preview in, say, Blender? To be compatible with the new pipe-line, this would either have to work with light as a texture (we could provide a standard one) or
* How many assumptions does the format make about how the shader works? Are they ever generated or manipulated in any way?
* I could theoretically leave the mesh rendering code as-is and depend on the meshes to all have shaders attached to them? If I read the specs correctly, they could just "include" a standard shader when in doubt.
* Would this allow you to still get a useful preview in, say, Blender? To be compatible with the new pipe-line, this would either have to work with light as a texture (we could provide a standard one) or
#ifdef things around in order to give a result close to what the engine would produce.* How many assumptions does the format make about how the shader works? Are they ever generated or manipulated in any way?
> I could theoretically leave the mesh rendering code as-is and depend on the meshes to all have shaders attached to them? If I read the specs correctly, they could just "include" a standard shader when in doubt.
I didn't read much into the OGRE specifications yet, but I think that's how it should be done -- otherwise we would need to merge the mesh shader and the light shader codes in some sensible way, no?
Well, if we want to support Ogre shaders. The question here is whether it would be easier somehow to just forbid this kind of thing and implement a shader that's compatible with how the meshes look like right now.
After all, we will probably have to maintain a non-shader-pipeline as well.
After all, we will probably have to maintain a non-shader-pipeline as well.
Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill
