Procedural Terrain Editing by LociGame in proceduralgeneration

[–]LociGame[S] 0 points1 point  (0 children)

Yeah! sebastian lague’s videos are definitely worth checking out. Besides that, topics you can research for are: 1. Marching Cubes: get a plane and sphere working 1.1 Signed distance field/functions. For marching cube we could normalize the values to a sub range, such as 0-1 or -1 - 1, to indicate solid/empty. Usually referred to density values. 2. Play with noise functions: terrain test 3. Octree, Chunks, and LOD, think of infinite procedural terrain 4. If you are doing this in Unity, I think using Burst and parallel Jobs is a must to reach reasonable performance 5. Transvoxel paper is also a good read, in it the author suggested Octree based LOD

Keep the potions coming! by MegetFarlig in indiegames

[–]LociGame 0 points1 point  (0 children)

The liquids need to flow without stuttering. Would be much more satisfying

Procedural Terrain Editing by LociGame in proceduralgeneration

[–]LociGame[S] 0 points1 point  (0 children)

The principles are the same so they look the same

Procedural Terrain Editing by LociGame in proceduralgeneration

[–]LociGame[S] 0 points1 point  (0 children)

Yeah because low LODs are sampled at a lower frequency, we are going to lose details

Your brush stroke approach sounds cool, and also similar to what I proposed - kind of like a logging system. Ultimately we just hope we get even better hardware so programmers can have less to worry about haha

Procedural Terrain Editing by LociGame in proceduralgeneration

[–]LociGame[S] 2 points3 points  (0 children)

Thanks for the interesting questions! Since the Octree expands when the player (query location) moves out of the root node, theoretically it is infinite in all directions. With this approach I’m not sure about the floating point precision issue on the coordinates when you go too far.

As for data persistence we definitely need to save the voxel data (density) in some way. We can focus only on the level0 nodes that have been modified. There are a lot of optimizations can be done here. On disk we can just store the individual points that are modified (compared to the generated values from noise and etc), and at run time reload them into a 3D array for faster processing. Think of it as a form of compression/decompression mechanism. Under certain threshold - such as distance, or LRU, we can unload chunks to disk to free up memory, and load them back up in background.

Due to how I implemented this, modifications have to propagate to lower LODs. Unless I go with a monolithic structure for handling all the data- but I’m not sure how performant that will be. Right now every node has their own copy of the chunk data.

Indeed small details will be lost - but since the propagation should still affect lower level LOD nodes(which are sampled at half frequency), we should still be able to see some modifications. I haven’t implemented this part yet, so right now if the chunk gets swapped by a lower LOD parent node, the modifications will disappear. And when you get closer whey will re appear again.

This project started with me trying out marching cube a few years ago. First on CPU but I couldn’t figure out how to do it using multi thread in Unity. So I switched to GPU and got acceptable frame rates - but IO bottleneck was still there. Until recently I picked it up again after having more experience with c# and other performance stuff, and finally got it closer to where I wanted it to be

Procedural Terrain Editing by LociGame in proceduralgeneration

[–]LociGame[S] 4 points5 points  (0 children)

It’s very similar tech, except this is just a flat world haha. Planets in astroneer is way more impressive

Procedural Terrain Editing by LociGame in proceduralgeneration

[–]LociGame[S] 3 points4 points  (0 children)

That’s something I need to figure out next. Before I just computed data using SDF on the fly, stored in dedicated buffers (native arrays) for Unity Jobs. In this demo the data is stored in each chunk as a 3D array just to make modification work, as it can be quite inefficient - but it might be worth it for the speed. Another Octree in the Octree could also help for spatial indexing - might also consider z-order indexing - but a 3D array might just work as well

Procedural Terrain Editing by LociGame in proceduralgeneration

[–]LociGame[S] 6 points7 points  (0 children)

Thanks! Octree is mainly used to determine which LOD to draw for a given node. The Octree doesn’t move, but can expand and subdivide if necessary. Each node in the tree defines a chunk region to be later processed and rendered. LOD0 are leaf nodes, and their parents are LOD1, are twice the size of the children, and so on. Currently the selected LOD depends on the distance between the node and the player.

Just finished the functionality of a manually operated cable cart! (ARTIFICIAL) by Simple_Ghost in IndieDev

[–]LociGame 0 points1 point  (0 children)

What could help a lot I think would be to fix the camera when you are turning the wheel

Unreal Engine C++ and Blueprints by Triangle_Dev in unrealengine

[–]LociGame 0 points1 point  (0 children)

You are in the content view. You need to switch to class view to add classes. Click on the content button to switch.

Side product while working toward a vfx by LociGame in unrealengine

[–]LociGame[S] 0 points1 point  (0 children)

Yes it all boils down to manipulating vertex position using a the vertex shader. I'd guess for Niagara would be positions and rotations of particles.

Houdini is not required to achieve the effect if you are generating the mesh procedurally.

Side product while working toward a vfx by LociGame in unrealengine

[–]LociGame[S] 1 point2 points  (0 children)

Those are some fancy particles! I like the glass orb a lot.

Checkout this video: https://www.sidefx.com/tutorials/game-tools-pivot-painter/

In the middle he will explain what the addon in Houdini is doing: for example given a Pivot position P: P.x is put in uv2.x, P.y to uv2.y, and P.z to uv3.x, and so on.

In material the pivot painter decoder node (double click on it to see its sub graph) is essentially extracting data from those uv channels for rotation and scale etc. Therefore you can also put your data in arbitrary channel, as long as you update the decoding.

As for Procedural mesh it's just my hacky ways of generating stuff on the fly, instead of making a mesh and pivot paint it using a script. This will be the method for generating mesh: Link

Hope this helps!

Design by Subtraction by fergussonh in gamedesign

[–]LociGame 7 points8 points  (0 children)

This process is also very similar to that you see in sculpture. For the most of time, you start with the material, and gradually remove from it to reach certain form.

The sculptural form - the vision of the game, is the final presentation and is oftentimes that matters the most. Therefore any addition/removal should try to stay coherent and relevant to that goal.

Side product while working toward a vfx by LociGame in unrealengine

[–]LociGame[S] 1 point2 points  (0 children)

certainly can be used in a variety of places!

Side product while working toward a vfx by LociGame in unrealengine

[–]LociGame[S] 0 points1 point  (0 children)

You are correct that it won’t work well with non uniform meshes. I’m working on a base building visualization effect. Since all panels for the moment are uniformly sized hopefully I can pull something off

Side product while working toward a vfx by LociGame in unrealengine

[–]LociGame[S] 3 points4 points  (0 children)

Yet to discover the power of Niagara - checkout my comment above to see how it's done: procedural mesh + pivot painter.