It would be easy to get it to work with only pixel shader 1.1, and then have a fallback (through code and material) that uses scaling and works with fixed function.
Assaf Raman wrote:This effect can be done without any shaders.
You can use scale (a modified scale that scales in the direction of the normal) and color change.
Why would you use the CPU and extra code with some nasty work arounds instead of a simple Ogre material+GPU method that everybody can use out of the box. This goes for alot of things that are made here on these forums.
You can very easily – just change it in the shaders. The shaders are very basic shaders and I think you can change them without any knowledge in shaders.
Assaf Raman wrote:You can very easily – just change it in the shaders. The shaders are very basic shaders and I think you can change them without any knowledge in shaders.
I agree, I have no knowledge of shaders and was able to change the workings of these 2 I ran up to a problem though, which your demo doesn't seem to suffer from. Perhaps that's because the Ogre model is more complex, but if I use a simple box model and this shader there's an obvious seam between the vertices of the glow. It looks a bit odd, so I'm going to try using a scaled scenenode instead.
Proud member of the OpenFRAG Game Development community
or just duplicate the mesh rescale & use another material with scene_blend add for the first head result and for the second just flip normals. Oldest trick in the book, way before shaders
Assaf Raman wrote:You can very easily – just change it in the shaders. The shaders are very basic shaders and I think you can change them without any knowledge in shaders.
I agree, I have no knowledge of shaders and was able to change the workings of these 2 I ran up to a problem though, which your demo doesn't seem to suffer from. Perhaps that's because the Ogre model is more complex, but if I use a simple box model and this shader there's an obvious seam between the vertices of the glow. It looks a bit odd, so I'm going to try using a scaled scenenode instead.
this problem also occurs with the robot.mesh. seems that the faces are translated a bit outward according to their normals only. so a right angle or close to one would have gaps in the glow.
i dont know how to do cg, anyone care to fix this?
I've asked around and apparently that's not possible with vertex shaders. I'm no expert though (this is my first experience with shaders ) so I may be wrong
Proud member of the OpenFRAG Game Development community
It's not possible to fix without modifying the original mesh normals. The problem is that at angular seams in the mesh, normals usually point in different directions. This is because when you generate normals for a mesh in a 3d modeller you usually define an angular threshold for "smoothing" the normals - if the threshold is exceeded the normals will point in different directions at seams (otherwise your sharp corners would appear smooth-ish when you render them in Ogre). You could fix this by making an actual copy of the geometry and then smoothing all normals without this threshold, but it probably isn't worth it.
You can't do anything about this in a vertex shader because per vertex the shader doesn't know anything about the surrounding vertices, so you can't change the normal direction in the shader.
If you want to avoid this, you have to use the scale approach, instead of moving the verts out along their normals. You can do the scale inside a shader as well instead of calling setScale on the mesh. Also, you should get the center of the bounding box and pass it to the shader, then get the direction from this position to the vertex position and move the verts out along this vector. If you just pass a scale matrix and use the origin of the mesh, unless the origin is directly in the center of the mesh it will scale out in a less friendly manner.
So which one is better? Either way we'll have to move the vertices out from the center and multiply them by a scale matrix. Using a shader this would have to be done every frame, but that may not be a problem as it's done on the GPU. I don't know if setScale() is done on the GPU, but I expect it isn't... it would be a one-time-only job though.
With my limited experience I'd say option 2 (using setScale rather then a shader) would be more efficient...
Proud member of the OpenFRAG Game Development community