Pathgrid rendering v2

[Aesylwinn]

There is one slight bug with the edge removal that I have to track down. Also, I need to test it a bit more extensively, but its pretty close to what I was envisioning.

[ghost]

We already have the pathgrid renderer in OpenMW. Shouldn't we turn that into a shared component used by both game and editor?

The code that modifies the geometry on data changes looks unnecessarily complicated. I suggest to just rebuild the entire grid when anything changes. The overhead should be negligible.

FWIW, the new rendering code is suboptimal as well. All points / edges should be combined into one Geometry for GPU-efficient rendering.

[Aesylwinn]

The code that modifies the geometry on data changes looks unnecessarily complicated. I suggest to just rebuild the entire grid when anything changes. The overhead should be negligible.

FWIW, the new rendering code is suboptimal as well. All points / edges should be combined into one Geometry for GPU-efficient rendering.

True enough. When constructing it I was torn between updating as needed and just dumping everything. I'm a bit inexperienced when it comes to optimization, and I guess I made the wrong choice.

As far as combinging all points/edges into one geometry, is that efficient even if adding normals to the mix? You can only have one vertex array, right? Potentially I could reuse the vertices from the points to shrink the amount of unused normals.

Also, I can understand the one Geometry approach being most optimal for the editor where everything is going to be on screen, but would it be optimal for the game where only a portion of those point/edges will be on screen at any point in time?

[zinnschlag]

We already have the pathgrid renderer in OpenMW. Shouldn't we turn that into a shared component used by both game and editor?

That is not a bad idea. This will at least give us consistent rendering between the two applications. But we need to consider that the editor needs additional editing functions (node selection). Can we tack them on in the editor without affecting OpenMW negatively?

Regarding the combined geometry: Wouldn't that be problematic for pathgrid editing?

[ghost]

Regarding the combined geometry: Wouldn't that be problematic for pathgrid editing?

We could maintain a map of triangle indices to pathgrid point indices. When the pathgrid is clicked, we check the triangle that was clicked on and can then deduce the pathgrid point that the triangle belongs to.

That is not a bad idea. This will at least give us consistent rendering between the two applications. But we need to consider that the editor needs additional editing functions (node selection). Can we tack them on in the editor without affecting OpenMW negatively?

Sure.

As far as combinging all points/edges into one geometry, is that efficient even if adding normals to the mix? You can only have one vertex array, right? Potentially I could reuse the vertices from the points to shrink the amount of unused normals.

Correct, combining the geometry does make for a bit of data duplication (i.e. higher GPU memory usage), but we don't really need to worry about that when the number of vertices is very low.

Also, I can understand the one Geometry approach being most optimal for the editor where everything is going to be on screen, but would it be optimal for the game where only a portion of those point/edges will be on screen at any point in time?

In general, drawing objects that are not on screen can be sub-optimal. GPUs will cull off-screen primitives before their pixel shader is executed, but there is still an overhead to the culling. Again though, the number of vertices here is so low that we don't need to care. Plus, the world is already divided into cells, so the pathgrid for a cell can be culled if that cell is not visible.

[ghost]

By the way, normals are not strictly required (unless you want to enable lighting/shading, but it doesn't seem to be enabled on this screenshot)

[ghost]

One more thing, the way that existing Geometry is being modified is not thread-safe. If you want to modify a "live" Geometry that may have been queued for rendering, you have a few options:

• set the Geometry's dataVariance to DYNAMIC. Not recommended because this makes the draw thread synchronize at the end of the frame -> low performance.
• remove the old Geometry and create a new one
• implement a form of double-buffering the data that is being modified (we do this for RigGeometry and MorphGeometry).

I guess that option 2 is the best here, if we are going to be recreating from scratch anyway.

[Aesylwinn]

We could maintain a map of triangle indices to pathgrid point indices. When the pathgrid is clicked, we check the triangle that was clicked on and can then deduce the pathgrid point that the triangle belongs to.

Correct me if I'm wrong, but the selection mode seems to also turn on some sort of wireframe mode. It may add a bit of complexity if the same has to be done for the nodes.

but it doesn't seem to be enabled on this screenshot

There actually are normals there, it's just that the light is coming straight down from above so its not noticeable unless you can also see the bottom of the diamond.

[Aesylwinn]

I posted some pictures with/without lighting on the forum. I have mixed opinions. It is easier to determine the position with the lighting, but it also looks a bit ugly. Especially the lines. Let me know what you prefer.

[Aesylwinn]

Well, I quite liked the gradiant. I toned it down a bit though (and changed it to blue).

[ghost]

Can we keep the original red-yellow color scheme? I'd say red is much easier to recognize than blue (seeing that the sky is usually blue), also it's nice to have points and edges in separate colors. Lastly, it would be nice to have visual consistency with the original engine. I don't know why the icon in OpenCS was made blue, but it should be very easy to change it.

The height offset seems excessive. I say we should get rid of that, since we need to know where exactly the pathgrid actually is when editing it. If there is a concern that points/lines will get submerged in terrain, then try using a glPolygonOffset to offset the depth comparison (while not actually changing the height of vertices).

[Aesylwinn]

About the height offset, I changed the shape so that the bottom of the diamond is where the point is located. In my opinion this made it much easier to see everything. It is different, but I think still intuitive.

I'll go ahead and make the edges separate colors. If Zinni can clarify on whether I misunderstood his comment or not, then I'll change the colors to a red and yellow color scheme.

[ghost]

I would have expected that the center of the shape signifies the pathgrid point's position.

[Aesylwinn]

That is a good point, but I think that after seeing how the pathgrid nodes are already placed, that a person would place them the same way, whether that is buried halfway into the ground or with the tip just touching the ground.

[zinnschlag]

The pathgrid should look similar to the pathgrid shown in the editor icons, so at least one of them need to be changed. IIRC there was an argument about the red version being problematic for people with impaired colour vision. I don't have the details at hand right now, sorry. Should be somewhere in the editor icon thread on the forum.

[Aesylwinn]

Here is the forum post I believe you are referencing. To be honest, I don't understand why not being able to distinguish between the color of the edge and the node is important functionally. However, I guess it's good to accommodate when possible.

[Aesylwinn]

I did make an attempt to use the glPolygonOffset, but I must not have been using it right because I saw no difference (at least not what I was expecting).
osg::ref_ptr<osg::PolygonOffset> polyOffset = new osg::PolygonOffset(1.0f, 1.0f); gridGeometry->getOrCreateStateSet()->setAttributeAndModes( polyOffset,osg::StateAttribute::OVERRIDE|osg::StateAttribute::ON);

[Aesylwinn]

So anyway, I believe that in its current state, the pathgrid rendering is functional and similar enough to the icon.

[zinnschlag]

@scrawl Does this look okay to you?

[ghost]

All good, I think.