Support for complexe shape

[SirJackblue]

Hello !

Recently, I started to work on a Voxel Engine, and your project helped me a lot !
I would like to add support for complexe shape, not only draw brick/voxel.
I understand how the Brick Render Component works but I have few questions concerning:

• How unreal normalize UByte4N, normally each byte will be normalized with this formula:
  divide to 255 = x / max_x * 255, where max_x is the highest byte value and x the current byte value.
  My question here is does Unreal follow this rule.
• How uint8 X is converted to UByte4N (I think each bytes has the value of X) ?
• What is the usage of the 4th bytes of the UByte4N ?
• If I use a Float4 instead of UByte4N for the ComponentPosition of the DataType, and I normalize it like a UByte4N, can I achieve what I want (complexe bricks like stairs, half-block, etc..) ?

Thank you in advance :)

Cordially, Jackblue

[iUltimateLP]

Personally, I'd use the Procedural Mesh Component for geometry which doesn't belong to the terrain. Example: I used the Procedural Mesh Component to create runtime-loaded meshes which I can place in the world (select a FBX file, it parses the fbx (using assimp) and gets the information out and populates a procedural mesh with it ). If you want custom shapes for the terrain, I'd take a look at @miguelemosreverte's branch, he implemented wedges on the terrain 😄

[SirJackblue]

Thank you for your reply @iUltimateLP !

I prefer to use the terrain grid, for performance and replication purpose, because those shapes I want to draw can be contained inside a brick shape. If I need to render a bigger model, yeah I use directly a mesh.

And I look at @miguelemosreverte's branch and I see nothing concerning vertex, he is using material & Ambient Occlusion if I understood correctly, to animate water.

Cordially, Jackblue

[iUltimateLP]

Oh, my bad, he removed the custom render code there. Maybe he sees this and answers you that question :)

[miguelemosreverte]

Oh! Thankfully I have just finished finals season so I am back, just in time! First of all, sure, lets do it!

Whats the hot thing these days? Last time I checked we where working on the water, hacking the Ambient Occlusion parameter to insert some other data I do not remember. As any hack, it was not a nice solution, but it really worked without to much modifications. About deleting stuff, yeah my bad, I did delete everything to do the pull thing from a clean state.

[miguelemosreverte]

@iUltimateLP is correct, I managed to modify vertex data like this:

by copying the data from a vertex to the one of the vertex below it.
Basically you take a brick index, right? Well, then you start counting down from its sides, until you hit bottom. For performance purposes, lets say you stop counting at 100. If the brick is 100 far from the floor next to it, then no modifications would be done.

But if it has a neighbor down below, then it will copy the vertex index that it wants, and paste it onto his own. Now its own vertex, and the one of the neighbor, have the same index, and so the GPU will render them as the same. You are not deleting vertices, just pulling them together. But the result is really satisfying because of Scheidecker use of World Texture Coordinates: They, (the textures) do not stretch, but texture information is procedurally created for them.

This can be used for less blocky mountains or for water surfaces, for when you simulate water with the bricks.

EDIT: Forgot to mention, it was not all roses, I recall having trouble with the normals. Because, sure, you can change vertex info, but remember the normals? Those are cooked so that the face number 6 of the brick, the one that should be facing up and you are forcing it to an angle, point up and reflects, well, what an horizontal surface would! Basically you cannot have it both ways, either you have cooked normal angles or you have dynamic voxel angles.

[miguelemosreverte]

About UByte4N, how did you end up using that term? It seems like a really low level data structure!
But it make sense, since your approach to complex blocks is to, having the same voxel data as before, have more vertices.

I would suggest the opposite. Voxel resolution could allow in the future for, well, more detailed worlds, and if that happen, you could just make high level objects made up of cubes.

But count me in for the trip!

[SirJackblue]

I'm happy someone heard my prayer !

Thank you for your clarifications, I found the UByte4N here:
https://github.com/AndrewScheidecker/BrickGame/blob/master/Plugins/BrickGrid/Source/BrickGrid/Private/BrickRenderComponent.cpp#L132

I am new in the amazing world of rendering, and I made the mistake of believing that ubyte4n had no floating point and I learned later that he was normalize by this doc:
https://msdn.microsoft.com/en-us/library/windows/desktop/bb322868(v=vs.85).aspx

So for me if I wanted to do more complex shapes I needed more precision and FBrickVertex struct was only allowed to make brick.

I have not fully understood for the voxel resolution, you mean increasing the accuracy of vertex data x, y, z ? I already create my system to determine the type of my brick and get informations like vertex, index, and normals to draw the shapes.

Finally, here is my Skype (mrjackblue) to make some developing session together if you want to.

[miguelemosreverte]

About the voxel resolution I mean that minecraft proposed to use a different kind of voxel type for certain complex shapes, and the opposite would be the way laser scan represent complex shapes, by using a million of voxels. A middle point that will come at some point in the future is where you still have big cubes, but actually they are made up of a grid of smaller cubes, and that is what allows for detail on complex shapes. That way a stair, like the ones in minecraft, is not a special kind of voxel, but an object made up by a combination of them. That is what I mean when I say that at some point in the future more resolution will be available and then this talk of low level vertex tweaking will be out of the window, because you will be happy with the amount of vertices given by the standard blocks.

Now: This is not the present, where visibility of far away blocks and refreshing of their states is still not a trivial problem. So, yes, we will have to copy the already existing solutions out there. And learn about low level vertex manipulation in the process!

[miguelemosreverte]

You have probably put more thought than me about this vertex problem. So, what are your ideas?

I agree with @iUltimateLP that stairs, for example, just screams Procedural Mesh Component, because as he said, it does not belong to the terrain.

Now terrain, that's another thing. And that I have thought of, and concluded that you do not need extra vertices, but processing power to move them around when LOD says its time to do so.

[SirJackblue]

For me the ideal would be an interface, with differents functions, to know if the type has a complex render. If yes, we override the function which return necessary vertices and indexes.
As explained in this post: http://www.blockstory.net/node/59

And after on the rendering loop we check if it's a complex render, if yes we add vertices and indexes, otherwise we draw a simple brick, but I don't think that is as simple as that.

For procedural mesh component, I'm afraid it will be glitchy, that it needs more performance, and the render isn't coherent (procedural mesh is displayed whereas the grid isn't displayed yet)
And for the LOD, if we want to save vertices, we can render standard bricks far away, and when the player comes close it renders the correct mesh.

[miguelemosreverte]

Sure. How about this:

Right now, the game sends batches of vertices to the GPU. Those are of a known size.
We could add a secondary vertex batch-sender, one that sends batches of exactly the same size, with all the objects that happen to fit inside of it.
The render component we know could be renamed as the main grid renderer, and this clone of his, the miscellaneous one.

There are many ideas to talk after this main one is decided, like the priorities of the objects that want to be rendered. But again, no need to talk about that yet.

Over here the objects waiting to be rendered, they all would be complex. Stairs, trees, all static in place and using the voxels system of coordinates.

One last thing, this object, they should have a boolean variable that states whether if not rendered as complex blocks they should not be rendered at all or rendered as normal blocks. This way tree leaves are rendered and complex windows are not so that the hole on the wall is still visible.

[SirJackblue]

What about increase size of batches vertices ?

[miguelemosreverte]

At the end of the day what I am saying is to send, along with the grid data, the objects seen by the player categorized by importance, distance, and complexity, just to name a few. This info would be used alongside the grid data by BrickRenderComponent.cpp after the grid is rendered, and sent to the GPU too, not all but only the amount that can be done without killing the FPS, being the ones chosen and their levels of details thought really well.

[miguelemosreverte]

About increasing the size of batches, you lose control. My solution adds tons of tweaking room.

[miguelemosreverte]

But is can be done, what you say. I mean, using a single batch with different data in it would be cleaner. What you do with that extra data is the important part. Making them separate only adds complexity.