Thanks mordentral!
Apologies for the late reply, Taces, but I think my posts in this thread might clear up a few things for you re: VertexColor.
Hope that helps!
Never mind, rather a late response than none! 
In the meantime I got Vertex colors working (I didn’'t know, that there is an extra parameter for it) and tried around a bit, to understand how they are working. Now I’m setting the BaseColor of the Material to the VertexColor, which works well for what I want to do.
[=Taces;167563]
Never mind, rather a late response than none! 
In the meantime I got Vertex colors working (I didn’'t know, that there is an extra parameter for it) and tried around a bit, to understand how they are working. Now I’m setting the BaseColor of the Material to the VertexColor, which works well for what I want to do.
[/]
Yeah I’ve been using vertex color as a material base for awhile with custom mesh, I did notice however that FColor::toDwcolor seems to encode the blue channel incorrectly and I had to manually pack and unpack colors instead when saving the data outside of an FColor struct.
Hey guys,
Thanks for keeping this going! I’ve been really busy on other stuff, so I haven’t been able to make updates to the wiki. Please do not hesitate to update the wiki page: A new, community-hosted Unreal Engine Wiki - Announcements and Releases - Unreal Engine Forums
I see that the project code has been linked and that’s a great help! If anyone wishes to revamp the page be my guest.
My last version was 4.2.1, so I have a lot of catching up to do…
Just wanted to give a fast feedback: I now got a real basic terrain generation working, thanks to the forum and the great Epic Community - Thank you!
This is how it looks so far (the colors in the bottom picture are just to show that each brick could easily have its own color - random is a great class 
):
http://www11.pic-upload.de/25.10.14/96oz8wrnvoff.png
http://www11.pic-upload.de/25.10.14/rbd3mt4ka6m.png
This took about 38s for 1024 Chunks to generate and has an acceptable memory footprint (about 1.1GB RAM in the Task-Manager in a packaged game), however there are probably still many optimizations left 
Taces
[=Taces;169258]
Just wanted to give a fast feedback: I now got a real basic terrain generation working, thanks to the forum and the great Epic Community - Thank you!
This is how it looks so far (the colors in the bottom picture are just to show that each brick could easily have its own color - random is a great class 
):
This took about 38s for 1024 Chunks to generate and has an acceptable memory footprint (about 1.1GB RAM in the Task-Manager in a packaged game), however there are probably still many optimizations left 
Taces
[/]
Go check out the FQueuedWork class, i’m using it with the FQueuedThreadPool to run a thread pool to generate chunks. Regenerating 1024 chunks of 32x32x128 takes about 2 seconds with it for me batching them across 4 threads. Granted I’m using PolyVox which is pretty fast compared to first effort self solutions but the threadpool class is sexy.
Also I run the chunks as components to a single main actor, that should have far less overhead than having an actor per chunk from what I understand.
Edit I didn’t notice the stat window at the bottom of your screenshot, you might already be threading them, if so my apologies.
[=mordentral;170269]
Go check out the FQueuedWork class, i’m using it with the FQueuedThreadPool to run a thread pool to generate chunks. Regenerating 1024 chunks of 32x32x128 takes about 2 seconds with it for me batching them across 4 threads. Granted I’m using PolyVox which is pretty fast compared to first effort self solutions but the threadpool class is sexy.
Also I run the chunks as components to a single main actor, that should have far less overhead than having an actor per chunk from what I understand.
Edit I didn’t notice the stat window at the bottom of your screenshot, you might already be threading them, if so my apologies.
[/]
I didn’t knew that class but reading the (rare) informations I found made me interested, since this seemed to be exactly what I needed (Many little Threads that are processed quickly after each other) so I gave it a try. Indeed I did use Threads before but I already noticed that a huge amount of the 38s was consumed by the creation of the threads (I used Ramas Tutorial on Multithreading). Apparently the FRunnable Interfaces isn’t made for a huge amount of little tasks. Anyway, I changed my Threads from FRunnable to FQueuedWork which is pretty simple and implemented FQueuedThreadPool in my project, pressed “Play” and was just like “… WHAT ?!”. It took 10s to generate and after a little tweaking with the amount of FQueuedThreadPools and FQueuedWorkers inside each of the pools I got it down to 4s(!). It now takes 4s to generate a world of 512512128 Blocks (16164 Chunks), which is incredibly fast to what I had before. At the moment I only use a single 2D Noise-Function as a proof of concept but anyway… Thank you mordentral, thank you, thank you, thank you! And the threadpool class is more than sexy, it’s the Jennifer Lawrence among the classes ;D
I don’t want to use PolyVox as I would like to use my own implementation (Well, “my own” is relative - The GMC from the wiki, a little modified to my needs).
I think at the moment it’s sufficient for me to implement each of the chunks as a single actor. But still, is it in fact far less overhead or just a bit? If it is indeed much less I’d give it a try ^^
Just try and batch them as much as possible across the threads, even with a thread pool you probably don’t want to open a new FQueuedWork for each chunk, instead have the first FQueuedWork update 1/4 of them, the next another 1/4, ect ect. Your original implementation appeared to be creating 1000+ threads O.o, you would be losing all of your gains (and more) from multithreading when launching all of them.
Also having the chunks as components not only allows you to have one actor from which you can reference all chunks and perform operations, but also cuts out any of the overhead the engine has that it does extra for an actor over a component. If you do stay with actors for the chunks at the very least you’ll want to disable them ticking, as 1024 actors ticking for no reason should be pretty taxing.
[=Taces;164262]
Hey,
first a big thanks for the Procedural Mesh Tutorial and the code! As far as I can see we are using FDynamicMeshVertex inside the constructor of the scene proxy, therefore it should be possible to set the color of the vertices, which is done by “const FColor VertexColor(255, 255, 255);” in the wiki code, as VertexColor is later assigned to the vertices. But no matter what values i choose for VertexColor, my triangles stay black. Possibly I get the concept of vertex colors wrong, but shouldn’t the whole triangle be like VertexColor if I’m assigning it to every vertice of the triangle?
Alternatively I’ll try to use a Texture for my mesh tomorrow, but as I only want the triangles/quads to have a single color it would be a bit “overpowered” to use a 1px1px Texture (or 22 whatever, simply that 1 pixel on the texture will represent one color) I think and in addition it would be much more flexible to be able to use FColor or anything alike I can simply adjust in code. (I haven’t got it working to get a MID on the mesh either).
Thanks in advance,
Taces
[/]
Firstly, I wanted to point out I mentioned the problem in page 2 of this thread, and ended up solving it here:
Secondly, I was wondering if anyone managed to get the custom mesh to work with SimulatedPhysics? I believe when I enabled it to simulated physics, it caused the mesh to not be created at all.
Thirdly, has anyone managed to get the wiki code to package into a game? I think people eluded to the problem, but I couldn’t exactly work out if it was the same problem I am having. When I try to package the code (custom mesh) from the wiki, it comes up with ‘BUILD FAILED’ during the packaging.
Now I managed to fix this, with the code posted in this thread.
Changing:
ModelBodySetup->InvalidatePhysicsData(); //Will not work in Packaged build
To:
ModelBodySetup->BodySetupGuid = FGuid::NewGuid();
This fixes the packaging problem. The collisions work in the editor BUT not in the packaged game.
>physics doesn’t work
>colouring verticies works
>packaging game works - but still has problems
Also for anyone interested, during the development of my project, I had alot of lag loading up new chunks (I am generating voxel terrain). The lag however seems to be not so great when creating a new mesh itself (updating a mesh for instance will not cause performance drops), but from creating the actual chunk itself:
AChunk* const NewChunk = World->SpawnActor<AChunk>(ChunkClass, SpawnLocation, SpawnRotation, SpawnParams);
I encountered this problem because I am not sure what the above function does, and was unaware it would lag the computer so much when creating new objects. I am used to the only performance hit being when you send new information to the gpu.
Assuming that you are working with version 4.5 you shouldn’t need to make that modification in order to have it work in a packaged build. You will need to remove the #if WITH_EDITOR but it should package fine on 4.5. Any other version and you are pretty much out of luck unless you rebuild from source with the changes that they made to allow out of editor collision baking.
My toy is working fine in packaged builds now.
Also as for the lag are you sure you aren’t running through the noise generator when it is created? That is normally a huge slowdown on generation.
[=mordentral;170661]
Just try and batch them as much as possible across the threads, even with a thread pool you probably don’t want to open a new FQueuedWork for each chunk, instead have the first FQueuedWork update 1/4 of them, the next another 1/4, ect ect. Your original implementation appeared to be creating 1000+ threads O.o, you would be losing all of your gains (and more) from multithreading when launching all of them.
Also having the chunks as components not only allows you to have one actor from which you can reference all chunks and perform operations, but also cuts out any of the overhead the engine has that it does extra for an actor over a component. If you do stay with actors for the chunks at the very least you’ll want to disable them ticking, as 1024 actors ticking for no reason should be pretty taxing.
[/]
In fact I had 2048 Threads (Two per chunk, one for Terrain Calculation and one for the Generation of the triangles) - Shame on me
I’ll give the batching and the Chunks as components a try and reply later if it improved performance any further.
[=Deus0;170766]
So first off I wanted to mention, on page 2 of this thread I asked about this problem of colouring a vertex. No one answered it. I eventually found the answer myself and posted it back here.
Secondly, it is yet to be solved, but would make this thread / custom mesh generation tutorial 10 times more useful. Has anyone managed to make it work with simulated physics, of the UBodysetup, set to true? As in gravity/forces to work on it? (Custom mesh physics is the dream)
Thirdly, I am getting problems with compiling the example into a packaged game.
Converting this:
//ModelBodySetup->InvalidatePhysicsData(); //Will not work in Packaged build
//ModelBodySetup->CreatePhysicsMeshes(); //Epic needs to add support for this
Into:
ModelBodySetup->ClearPhysicsMeshes();
ModelBodySetup->BodySetupGuid = FGuid::NewGuid();
[/]
For the first one: If I remember correctly this was were I found out how to use the Vertex color correctly, but it took me quite some time to realize that you meant the parameter “VertexColor” in your post, respectively that there is a parameter for the VertexColor you need to add manually to your material. After I added that one it worked out well.
I agree with you that custom mesh physics would be really great but as I didn’t need it so far I unfortunately didn’t do any research towards that direction.
As for the packaging: I kept the lines you commented out and it packages and runs well for me as .exe (UE 4.5), though I didn’t had the to test collision in the packaged game, but since it works in the editor and there are no Errors I’d suppose that does work.
Such speedy responses!! haha
’ the changes that they made to allow out of editor collision baking.’ Umm well, i’ve had this problem from all the builds 4.0 to 4.4, I haven’t yet updated to 4.5. But as you mentioned they fixed this? That’s really** good news** ~ I can finally share my game with people :D:D.
Well my plan was to make voxel based ships as well. So physics is a must. Also if I could make items out of custom meshes as well, it would be a lot better. Well I am probably too ambitious, but for one person project generating a lot of assets is a lot more efficient. I think mentioned something in another post regarding the physics of custom meshes, but no one has addressed it directly.
As for the lag problem, I moved everything on their own threads, except for the triangle uploading part. (So basically all the generation of triangle data ~ terrain ~ is done on its own thread) So I thought this uploading of triangles was the lag, but after I made the process a lot better managed I found it to be the World->SpawnActor function to be the cause of the lag.
Haha, yeah
I’m curious, what is your game about?
Alright, thats strange… For me copying the triangle mesh over seemed to be a bottleneck, so I changed the FGeneratedMeshTriangle struct to (If anybody else might encounter this problem):
USTRUCT()
struct FGeneratedMeshTriangle
{
GENERATED_USTRUCT_BODY()
uint8 X0;
uint8 Y0;
uint8 Z0;
uint8 X1;
uint8 Y1;
uint8 Z1;
uint8 X2;
uint8 Y2;
uint8 Z2;
FColor TriangleColor;
};
said on the first site:
[=;17621]
I cant post the code here for legal reasons, but check out SphereComponent.cpp
and the AggGeom.
adding to AggGeom you can create a physics composite shape to match your mesh!
This does require a lot of careful manual arrangement, just like the UE4 Physics Editor / Phat.
So you will have to do this per shape that you create
[/]
Maybe this helps?
Have you tried changing the Chunks or whatever you are creating from an Actor to a Component, as mordentral suggested? I haven’t yet done it myself, so I cant say if it really helps but I’m going to try it out now
Hi all, I am late to this all, but I’ve updated the Wiki page and the ProceduralMesh repository.
[=mordentral;165240]
For the final argument of ‘CreatePrimitiveUniformBufferImmediate’ I get sporadic crashes if I don’t True it.
[/]
I’ve look a bit at the Unreal Engine code to better understand how they use this:
BatchElement.PrimitiveUniformBuffer = CreatePrimitiveUniformBufferImmediate(GetLocalToWorld(), GetBounds(), GetLocalBounds(), true, UseEditorDepthTest());
It works for me in cooked game under 64 bits.
Cheers!
I had to put in a fix to get the .cpp to compile on UDk4.5 / VS2013
GeneratedMeshComponent.cpp line 195
from:
MaterialProxy = &WireframeMaterialInstance;
To:
MaterialProxy = **(FMaterialRenderProxy*)** &WireframeMaterialInstance;
I would try and fix it, check in, but I’m a total n00b so unsure how to do that.
I had a few minutes to wait for all platforms to build so I got myself a fork and checked the fix in. Now compiles.
[=PompeyPaul;171564]
I had a few minutes to wait for all platforms to build so I got myself a fork and checked the fix in. Now compiles.
[/]
It should compile just fine as FColoredMaterialRenderProxy has FMaterialRenderProxy as its public parent class and it is perfectly fine to use it like that, you must have overzealous compiler settings enabled. It doesn’t hurt anything to cast to it, but it shouldn’t be strictly necessary going from child to parent pointers as far as I am aware.
[=PompeyPaul;171564]
I had a few minutes to wait for all platforms to build so I got myself a fork and checked the fix in. Now compiles.
[/]
Oh, and in the meantime I have reverted those few lines ; I now match the CustomMeshComponent from Epic.
[=mordentral;171619]
It should compile just fine as FColoredMaterialRenderProxy has FMaterialRenderProxy as its public parent class and it is perfectly fine to use it like that, you must have overzealous compiler settings enabled. It doesn’t hurt anything to cast to it, but it shouldn’t be strictly necessary going from child to parent pointers as far as I am aware.
[/]
You are right - I just looked in my code and I didn’t do the change either and it compiles fine for me.