Thank you for all of this info. I have "is partitioned" in the pcg component enabled. I have a closed loop spline in the scene that pcg uses via spline sampler to get interior points and spawn meshes. When i enable is partitioned, i see in the outliner the separate PCG Partition actors that now get created under the PCGWorldActor, but each of them is identical.. when you select each one individually, it highlights in the scene the entire generated area, instead of highlighting the individual 'sections' like shown in this video. it's as if each section is the size of the entire spline area and they're placed in the same location. The names of the PCG Partition actors are all the same also.
You are duplicating the work, the spline is sampled entirely on all partition actors. Check again the pitfalls section. You can try Cull Points Outside Actor Bounds also (I use it in Episode 8)
Great to have another video from you! Do you have any tips for situations where your cameras are always seeing far into the distance (i.e. aerial shots)?
@@adrien_logut So it’s not recommended to use Hi-gen with runtime for meshes that are far away? I’ve set up 2 grids, one small and one large, merged them, then used the distance node to essentially get an inner grid and an outer grid. Then I used no performance friendly settings for the big grid and quality settings for the inner grid. Is this not recommended?
Can you cover the "Get Texture Data" node and how to make it work with PCG partition and not blow up the RAM usage? I have the need to sample a large map (8km by 8km) and a large texture covering it (4K)
I think we discovered an issue with the texture that just draw more and more memory, so we'll have to investigate that front. I would recommend to use the Get Texture Data at the unbounded level and sample it downstream.
Great video like always! Can i use this knowledge and make a video based on it for my community! Ofc i’ll shout out your channel and put a link to follow you! Great work as always!🙌
Je rencontre quelques problèmes avec ce système, lorsque je coche l'option "is partitionned" elle reste décochée et quand je la force en BP la génération prends beaucoup plus longtemps (mon composant PCG est intégré dans un acteur)
wow, thanks this demonstration. Is it a good idea to use this technic on "low platform" like Switch ? I do not know if realtime generation cost way too much for this kind of device.
I haven't played with low end platforms, so I can't say for sure, but I don't see why it could not be used. I think the most important there would it to be paired with a Quality Branch node so you adapt the density and perhaps even the meshes themselves for different quality settings.
This video helped me indeed a lot! Was struggling with partitioning for a while now. Much appreciated! But one question though. How do you combine runtime generation and offline generation? Taking the forest as an example. Trees should never disappear and HLODs are build. This is one graph. Then I need to create a second graph to get the runtime functionality for the undergrowth, right? But how do I get the result of the first graph, the trees, into my second graph so I can scatter foliage around trees?
Haha yes indeed that's the follow up video I want to make because this one was already long! You can have 2 components, one that is generated offline and has all its relevent data plugged into the output node. And a second one, running at runtime that can query this data with "Get PCG Component Data" or "Get Actor Data" with "Get PCG Component data" mode :)
@@adrien_logut Ahh. This information already helps a lot. Also thought, that there must be a "Get Data" node. Good to know. Will give it a try later :) EDIT: Works perfectly fine :)
This plugin is awesome and works well with impostors. Only question i have: How to setup PCG to not take up the entire CPU pipeline? If I make a mistake with the settings (oops, generated 256M points...), it always hangs up and sometimes I have to restart the editor... Is there not a setting config to limit the PCG tasks taking over the editor?
Unfortunately there is no safeguard like this as it is difficult to implement and have a good default value. You have in some cases the opportunity to cancel the generation, on the component and in 5.5 directly in the notification window. But if the node that has too many points don't give back the control to the engine, you're screwed.
It's not different methods, they are using the same underlying system, just for different purposes. Partition (normal or Hi-Gen) is the way to go for big maps, with runtime gen for details.
I tried using three different rocks, but the seedlings didn’t work on them. I went back to using just one rock, and it worked. I think we need to set up a separate spawning node and a named reroute for each rock we want to use.
That's because the mesh sampler has the rock hard-coded. If you have multiple rocks, you need to have a mesh sampler per different mesh. I'll show that in my next video, but you can use an attribute partition after the static mesh sampler to Partition per different mesh and use that in a loop where you can extract the mesh, do the sampling and output the sampling data.
@@adrien_logut Very cool if you'll cover that in the next tutorial! Also, if you can cover a little about the biomecore graph, especially the biome cache and the debug biome cache, I find it really cool to procedurally generate different biome types using the "texture to project on." I know it's well explained in the documentation, but I think it is part of the process of generating entire worlds with all the complexity permitted by PCG.
@@adrien_logut It's okay, but I think the topic of your video is closely related to Biome Core, and if anyone here could easily understand what's happening in that graph to explain it in simpler terms, it's you.
@@adrien_loguthow would that work? You can only use one mesh per mesh sampler node? Can you have an array or meshes to feed in and override the static mesh of the mesh sampler?
Is Partitioned is already doing that for a quick and easy partitioning. There is no "one size fits all" as we don't have all the information and it's often very dependent to what you are trying to achieve.
Looks like a ton of work went into this jeeez
Super impressive man
Thank you for all of this info. I have "is partitioned" in the pcg component enabled. I have a closed loop spline in the scene that pcg uses via spline sampler to get interior points and spawn meshes. When i enable is partitioned, i see in the outliner the separate PCG Partition actors that now get created under the PCGWorldActor, but each of them is identical.. when you select each one individually, it highlights in the scene the entire generated area, instead of highlighting the individual 'sections' like shown in this video. it's as if each section is the size of the entire spline area and they're placed in the same location. The names of the PCG Partition actors are all the same also.
You are duplicating the work, the spline is sampled entirely on all partition actors. Check again the pitfalls section. You can try Cull Points Outside Actor Bounds also (I use it in Episode 8)
Genius, thank you so much!
Great to have another video from you! Do you have any tips for situations where your cameras are always seeing far into the distance (i.e. aerial shots)?
In that case, it's probably better to combine offline generation, HLODs and runtime gen for close range.
@@adrien_logut So it’s not recommended to use Hi-gen with runtime for meshes that are far away? I’ve set up 2 grids, one small and one large, merged them, then used the distance node to essentially get an inner grid and an outer grid. Then I used no performance friendly settings for the big grid and quality settings for the inner grid. Is this not recommended?
Why not using the "Cull Points Outside Actor Bounds" node instead of the intersection one?
Why not? :)
They both do the same thing I use the other one in the next video.
@@adrien_logut Ah good. I was just wondering if there was any specific advantages...
Can you cover the "Get Texture Data" node and how to make it work with PCG partition and not blow up the RAM usage? I have the need to sample a large map (8km by 8km) and a large texture covering it (4K)
I think we discovered an issue with the texture that just draw more and more memory, so we'll have to investigate that front.
I would recommend to use the Get Texture Data at the unbounded level and sample it downstream.
Great video like always! Can i use this knowledge and make a video based on it for my community! Ofc i’ll shout out your channel and put a link to follow you!
Great work as always!🙌
Of course :)
Je rencontre quelques problèmes avec ce système, lorsque je coche l'option "is partitionned" elle reste décochée et quand je la force en BP la génération prends beaucoup plus longtemps (mon composant PCG est intégré dans un acteur)
Dans le cas des blueprints, ça sera fixé dans 5.5.
@@adrien_logut Ok merci!
wow, thanks this demonstration. Is it a good idea to use this technic on "low platform" like Switch ? I do not know if realtime generation cost way too much for this kind of device.
I haven't played with low end platforms, so I can't say for sure, but I don't see why it could not be used.
I think the most important there would it to be paired with a Quality Branch node so you adapt the density and perhaps even the meshes themselves for different quality settings.
This video helped me indeed a lot! Was struggling with partitioning for a while now.
Much appreciated!
But one question though.
How do you combine runtime generation and offline generation?
Taking the forest as an example. Trees should never disappear and HLODs are build. This is one graph.
Then I need to create a second graph to get the runtime functionality for the undergrowth, right? But how do I get the result of the first graph, the trees, into my second graph so I can scatter foliage around trees?
Haha yes indeed that's the follow up video I want to make because this one was already long!
You can have 2 components, one that is generated offline and has all its relevent data plugged into the output node.
And a second one, running at runtime that can query this data with "Get PCG Component Data" or "Get Actor Data" with "Get PCG Component data" mode :)
@@adrien_logut Ahh. This information already helps a lot. Also thought, that there must be a "Get Data" node. Good to know. Will give it a try later :)
EDIT: Works perfectly fine :)
This plugin is awesome and works well with impostors. Only question i have: How to setup PCG to not take up the entire CPU pipeline? If I make a mistake with the settings (oops, generated 256M points...), it always hangs up and sometimes I have to restart the editor... Is there not a setting config to limit the PCG tasks taking over the editor?
Unfortunately there is no safeguard like this as it is difficult to implement and have a good default value.
You have in some cases the opportunity to cancel the generation, on the component and in 5.5 directly in the notification window. But if the node that has too many points don't give back the control to the engine, you're screwed.
@@adrien_logut Ha! Well, I guess I learn something every time I make this mistake. Thanks so much for your work!
But which method is the most optimized for open world? Which one to choose from the 3?
It's not different methods, they are using the same underlying system, just for different purposes.
Partition (normal or Hi-Gen) is the way to go for big maps, with runtime gen for details.
@@adrien_logut OK. Thank you very much!
I tried using three different rocks, but the seedlings didn’t work on them. I went back to using just one rock, and it worked. I think we need to set up a separate spawning node and a named reroute for each rock we want to use.
That's because the mesh sampler has the rock hard-coded. If you have multiple rocks, you need to have a mesh sampler per different mesh.
I'll show that in my next video, but you can use an attribute partition after the static mesh sampler to Partition per different mesh and use that in a loop where you can extract the mesh, do the sampling and output the sampling data.
@@adrien_logut Very cool if you'll cover that in the next tutorial! Also, if you can cover a little about the biomecore graph, especially the biome cache and the debug biome cache, I find it really cool to procedurally generate different biome types using the "texture to project on." I know it's well explained in the documentation, but I think it is part of the process of generating entire worlds with all the complexity permitted by PCG.
I don't plan to talk about Biome Core because I didn't have to time to dive too deep into it yet!
@@adrien_logut It's okay, but I think the topic of your video is closely related to Biome Core, and if anyone here could easily understand what's happening in that graph to explain it in simpler terms, it's you.
@@adrien_loguthow would that work? You can only use one mesh per mesh sampler node? Can you have an array or meshes to feed in and override the static mesh of the mesh sampler?
🐐 🐐 🐐
Amazing but it seems complex, would be cool to just have all those as options in a basic pcg graph no?
Not sure I follow, what options and how basic the graph would be?
@@adrien_logut I mean having one pcg graph, the basic one, that you scale on all over the world and it will partition and stuff automatically
Is Partitioned is already doing that for a quick and easy partitioning. There is no "one size fits all" as we don't have all the information and it's often very dependent to what you are trying to achieve.