Does anybody know how make the generated mesh draw to the custom depth buffer?
I tried setting the bRenderCustomDepth property on the mesh, but it did not do anything.
Hi there!
I ended up doing this:
But i have a couple of issues:
The materials are wrong:
Also to dynamicaly update the mesh (add verticies, remove verticies) is there any better alternative with ue4 rhi?
I see FRenderResource object has BeginUpdateResourceRHI but i don’t really understand how to use it or what can i do with this method.
[=;195577]
Hey guys,
I ended up doing this:
But i have a couple of issues:
The materials are wrong:
Also to dynamicaly update the mesh (add verticies, remove verticies) is there any better alternative with ue4 rhi?
I see FRenderResource object has BeginUpdateResourceRHI but i don’t really understand how to use it or what can i do with this method.
[/]
The easiest way of handling landscape materials would be to use worldspace position texture uvs/tiling and triplaner projection then you won’t have to calculate and send the uvs with the vertex data to the video card and you won’t have to worry about material borders. (there are multiple examples of triplaner texturing around for UDK that pretty much work as is, there are also materials nodes built in for landscape that handle it as well, they just didn’t suit my purposes).
You can also get a cross of ddx and ddy material nodes and use it as the normal as well if you set the material to not use tangent space normals, then you also can not send the normals to the video card.
As soon as I put CreatePhysicsState();after ModelBodySetup->CreatePhysicsMeshes(); my OutputLog is getting spammed with this errors:
LogPhysics:Warning: PHYSX: ..\..\PhysXExtensions\src\ExtRigidBodyExt.cpp (234) 4 : computeMassAndInertia: Dynamic actor with illegal collision shapes
LogPhysics:Warning: PHYSX: ..\..\PhysXExtensions\src\ExtRigidBodyExt.cpp (283) 4 : PxRigidBodyExt::updateMassAndInertia: Mass and inertia computation failed, setting mass to 1 and inertia to (1,1,1)
The mesh is still rendered and collision works as well, but I’d still like to know what causes this errors to appear. Does anybody have a guess how to fix this?
Taces
P.S.: Merry Christmas 
[=Taces;196924]
The mesh is still rendered and collision works as well, but I’d still like to know what causes this errors to appear. Does anybody have a guess how to fix this?
[/]
I do not know how to fix this, but you can suppress the warning by putting the following before your call to CreatePhysicsState:
LOG_SCOPE_VERBOSITY_OVERRIDE(LogPhysics, ELogVerbosity::Error);
I made my custom components EComponentMobility::Stationary to avoid throwing that warning. Don’t ask me why it does it though, it is perfectly fine collision mesh shapes for mine as well and I haven’t sorted through the source since that removed it.
Oh I also don’t remember it ever throwing that warning pre-4.6 and only noticed it recently.
[=mordentral;197416]
Oh I also don’t remember it ever throwing that warning pre-4.6 and only noticed it recently.
[/]
Same here.
Apart from that problem I rewrote the generation of my terrain, without touching the actual mesh code and the warnings are gone - without having to change the Mobility… Pretty Strange. Though I’m not sure if collision still works how I want it.
How many vertices is that? I keep trying to create terrain in a similar manor but cant seem to keep my ram down.
Quite an interesting topic and it’s kind of weird to see the engine doesn’t have support for modifying terrain during runtime.
I’ve spent about a week with the engine now, hands on running through tutorials and examples and I’m very impressed (coming from Unity). This one thing worries me though because I know I’ll have to tackle this at one point or another.
I’m talking about having a large terrain, generated on demand from source data (heightmaps, textures, masks) with tiles being generated and shown where ever the camera happens to move. I could accomplish that with ease in Unity previously, I simply had a grid of terrain instances that I could move around and just assign them new heightmaps and textures when needed. But trying to accomplish the same in UE4 seems rather difficult. I’ve checked the code on this thread and it seems quite low-level, I’m a little surprised there isn’t any higher level solution available. Since we can’t use the built-in terrain we’re missing on a lot of extremely nice-to-have features - having to build everything from ground up seems quite a daunting task.
I’d like to ask for a little advice here: how should I proceed? I have a need for ~1000km x 1000km sized terrain area, impossible to implement with a single terrain (and I’m aware of the floating point accuracy problems, previously I overcame this with floating origin). How huge of a task do you think it would be to implement a terrain system by taking advantage of the code presented here? Also, how to deal with LODding since we don’t have the advantages of the native terrain system?
Also there was a related question asked before and answered: How do I procedurally generate landscape? - World Creation - Epic Developer Community Forums
It appears there was an open feature request for allowing runtime landscape modifications - but I haven’t read anything about any plans to do that so far, and the roadmap has no mention of it: Trello
I just hope this feature request isn’t forgotten. I see it as a pretty important feature.
I get an error:
Error 1 error C2079: ‘AProceduralTriangleActor’ uses undefined class ‘PROCEDURALMESH_API’
In the proceduralcubeactor.h, proceduraltriangleactor.h, etc classes. Deleting the PROCEDURALMESH_API declaration in the header files fixes this, but I don’t like deleting things that might be important. I was wondering what the PROCEDURALMESH_API does.
, I had to do the same thing. Working so far but yeah bothers me too. This thread and the wiki article have been so helpful to me. I feel I have to contribute.
There’s a bug in ProceduralMeshComponent.cpp
bool UProceduralMeshComponent::GetPhysicsTriMeshData(struct FTriMeshCollisionData* CollisionData, bool InUseAllTriData)
...
CollisionData->MaterialIndices.Add(i);
will cause a crash if doing a linetrace sample with bReturnPhysicalMaterial = true;
It should be set to the material index of the object or triangle or just
CollisionData->MaterialIndices.Add(0);
Here’s my progress on this, Marching Cubes Voxel system with realtime Simplex noise generation (takes about 0.5 sec. per mesh).
So you got this with the project I hosted on : it is a flag named after the name of the module of code (here the name of the UE4 project, ProceduralMesh). It tell the Unreal Build Tool or the compiler to export those symbols as a public API for other modules of your project.
So if you import the sample code into one of your project that you named otherwise, you have to Rename the flag accordingly.
You can also remove it altogether if you don’t need multiple game modules.
Cheers!
Ok, makes sense now.
1 more question - Is it yet possible to set the vertex normals?
The present code does some normal calculation.
Also, someone else on this thread provided code snippets to do smooth normals, please check previous pages.
Cheers.
[=;200540]
The present code does some normal calculation.
Also, someone else on this thread provided code snippets to do smooth normals, please check previous pages.
Cheers.
[/]
I found the code snippets that allow for smooth faces. It basically removes duplicate vertices in the vertex buffer which would automatically average the vertex normals. I think I would need to come up with a way to store the faces that need to be smoothed.
I’m getting some normal wierdness with two triangles:
The winding order it the same, but it’s calculating the normals backwards from each other.
[=;203410]
The winding order it the same, but it’s calculating the normals backwards from each other.
[/]
I think your normals are okay, otherwise you would not even be able to see one of the triangles (except if you had a two-sided material).
Looks more like the texture tangents are not calculated correctly. Look where the TangentBasisComponents is set in the VertexFactory of your generated mesh.
I had the same problem and correctly calculating the tangents fixed it for me.
That definitely the issue. I’ve modified the proceduralmeshcomponent files so that they now require tangent inputs.
On a side note, I tried out the merging vertex algorithm from page 2 but it doesn’t work well with cubes that share verts (like a cabinet). I’m thinking that by averaging the normals and tangents of two verts that share the same space I can make the combined faces smooth.
It’s might be a dump question.
But i wonder if there is a solution to asynchronously generate the mesh without blocking the render and the game thread?
Right now if i generate a bigger mesh, the editor freezes.
AndrewScheidecker did something to solve this issue:
https://.com/AndrewScheidecker/BrickGame/blob/master/Plugins/BrickGrid/Source/BrickGrid/Classes/BrickGridComponent.h#L317
So is there any alternative? Like the level streaming in the engine?
Thanks!
[=;206974]
But i wonder if there is a solution to asynchronously generate the mesh without blocking the render and the game thread?
Right now if i generate a bigger mesh, the editor freezes.
[/]
You can of course generate the mesh data (vertices, normals, etc) in a separate thread, but as far as I know, you can only push this data to the engine during the render thread. If the mesh you update is very big then the engine also has to do a lot of work (building geometry, collision data, apply materials, rendering, …), which can cause a noticable stutter.
You can decrease the size of your updated mesh by dividing it into chunks (which is also what AndrewScheidecker did) and only update individual chunks. If you have to update all of them you can still spread the update over several frames so it is not as noticable to the player.