Rendering Displacements

[snake-biscuits]

The current brush system doesn't have indices for the vertices calculated to represent displacements. This is because displacements have a consistent pattern. Meaning instanced draw calls & triangle strips are a potential optimisation available in this case. However, this would require tracking the power of stored displacements and utilities.render.manager.find_gaps using this info to keep displacements of similar powers together.

Using a tesselation shader and uniform buffer to shape displacements would be a further optimisation, but adds a lot of complexity. (probably a very bad idea then)

it'd be crazy clever to store only the pattern of a power 2 and a power 3, then use some draw call magic to offset the indices to the start of each displacement in the vertex buffer, but that's also very complex and would likely take many months to work out, if it is at all possible.

For now, the index buffer entry for each displacement must be calculated at when organsing buffer writes (render.manager.add_brushes).

[snake-biscuits]

Perhaps render.manager.add_brushes should be abstracted to taking vertex & index data of the same renderable_type, so we don't have to write a function for each renderable_type.

[snake-biscuits]

Converting brushes into vertex & index data may as well be functions in utilities.render as well. It would greatly reduce clutter in the solid class and might help with thinking how the class is mutated (brush operations like clipping, translation, rotation etc.)

The pipeline for communicating changes made to brushes to the render.manager will need to be considered as we move towards selection and basic CRDT operations.

[snake-biscuits]

As a lot of code for turning brushes into renderables moves to utilities.render, a method for communicating selection (for highlighting) & changes to brushes that are already being rendered to the render.manager needs to worked out.

[snake-biscuits]

Renderables are now handles exclusively in utilities.render, however the render.manager method find_gaps isn't working as intended (displacement vertex data is overriding brushes).

However, fixing this is going to wait until the move from fbs to cx_Freeze has been performed (Issue #13)

[snake-biscuits]

The cx_Freeze move is only half complete (ditched fbs & begun writing a build script), but I went and fixed displacements anyway. Turns out brush entities were being ignored too, so I've added them in too.

QtPyHammer now renders everything but point entites (props, logic, spawnpoints etc.) More than enough for 0.0.6! now for selecting and editing those objects (with CRDT of course)

[snake-biscuits]

Looking at test_maps/sdk_pl_goldrush.vmf it's clear that when subdivisions are used on a displacement, this data is stored and rendered differently.

The iconic arches in the oob of the map look far chunkier than they are in game, more work needs to go into interpreting these displacements.

[snake-biscuits]

The render_manager's hide methods have broken when it comes to hiding displacement's source brushes seems that when subtracting spans some things are getting deleted that shouldn't be Resulting in very messy buffer maps & crashes for the visgroups prototype

[snake-biscuits]

Thanks to a chat with ficool2 (hammer++ dev), we know that in the code, hammer applies catmull-clark subdivision to displacements, how sewing affects this is unknown at present.

[snake-biscuits]

int bSubdivided = ( int )IsSubdivided();
...
float ratio = 1.0f / ( float )( pPoint->m_uValence * pPoint->m_uValence );

TF2M Discord conversation