No, I was using heightblend using RGBA information for paint co-ordinates and then adding detail with non-weighted layers assigned, I even tried to add an Alpha blend. I messed around with the terrain system for about 2 months and covered just about every tutorial / doc etc. out there. http://www.youtube.com/watch?v=K9WTKK9f1b8
As said the only thing that really works is to export .RAW weightmaps from world machine with a splat converter to get it just right. Lot’s of trial and error, but it works just fine. There is also an with component overlay for SM blending, if you use a non power 2 components with a color map it’ll cause seams…
Fine if you’re doing single tiles, if you’re using world machine you can’t select the amount of components per tile.
Resolution independent sub tile painted terrain is a much better solution.
how would you do ? I have a “grass” layer that would be a good “base”. I set the preview weight to 1 and the others to 0 but I thought that only affected the material editor.
That’s a weightmap solution, which as said works fine and there are better ways of manipulating weightmaps than that…
I appreciate the help everyone, but end of the day if a lot of it doesn’t get sorted by the beginning of next year I’ll have to re-evaluate the engine and as whole. We may end up re-writing the terrain system and building a better deferred rendering solution…
Something I’m trying to avoid at all costs for the moment, but the only other option is Unity 5.0… Meh!
I kind of jinxed it… I had 3 crashes today by working with particles and re-importing mesh shapes over and over. I’ve managed to confirm the theory that the engine does crash D:
Well I finally fixed that problem with using Global Illumination. However trying to pain a terrain the sharers compile every time I change a layer. However the terrain painting tool is really bad. I have used so many toolsets that do not have the issues the terrain painter has… So the shaders complining every single time I change a layer is par for the course in something so broken.
I was talking about the layer infos in the landscape editor, not anything inside the material. When you create the layer info for each of your layers, you can choose from weight-blended or non-weight-blended. Weight-blended layer infos are normalized against each other, so will total to 100%, non-weight-blended layer infos are all independent and ignore each other.
People often run into trouble if they use the older “Landscape Layer Weight” nodes in the material (which have a “base” input which isn’t itself a layer) with blended layer-infos instead of the newer “Landscape Layer Blend” node. If you’re using the latter, you are probably already set up right and just need to paint your whole landscape with your chosen base layer before you start painting anything else (the component brush is good for ).
We need to do some work on the landscape create process so that a “base” blended layer can be designated which will be auto-filled across the whole landscape, I think.
I’ve seen a few Epic engineers say , it defeats the point of using Splat (RGBA) / weightmaps to cover the terrain. You may manually paint roads etc. and detail paint, but never in a sandbox setup would you ever manually paint the whole terrain. Especially when it’s a larger game, imagine trying to replicate a world machine splat by hand over a 30KM2 stretch of terrain? The documentation doesn’t cover the way that works, whether it’s the correct way or not.
Landscape Layer Weight nodes and .RAW splat weightmaps are the only safe way to go, which is fine it works. But there are still limitations there, because you need a Gaussian blur to blend the weightmaps, due to your resolution dependant vertex paint setup. Which is by far not the best way of doing things…
On the list of problems though, a bit of blocky paint isn’t exactly high.
FYI, thread spawned various discussions internally on build stability and processes and we are taking very seriously.
On the engineering side we have some work cut out ranging from improved automation (prevention) to easier association of callstacks to user reports (debugging).
We are also talking about how we can ensure having good communication channels open so we are aware when you guys run into issues and can help. That to me is the most important aspect as we will never get things 100% right out of the box. The success metric to me is whether we can make it work for you together with you.
We really appreciate it as others surely do, get the core concepts down… Base rendering / terrain and stability as I mentioned on page 1, which we both require for success. Then build on what’s already quite frankly one of the best engines ever made, not just licking boot either I am very impressed.
Thank you Daniel for getting us back on topic and that really was the main reason for starting . I wasn’t trying to grip I just wanted to discuss and see if we could work on a more stable builds. I was getting worried the thread was turning into a gripe fest and that wasn’t my intention. I appreciate the release for 4.5.1 and the internal discussions. Your openness and listening to the feedback of your users is unheard of and will result in a far superior product and development experience. Thank you for your time and effort and for the release of 4.5.1!!!
I had to resurrect an old thread but I really hope you can continue to move to stable releases. It got better for a while in 4.7 but I have to say, 4.8.3 is without a doubt the most crash prone version of the editor I have ever used. I don’t go 5 minutes without a crash. I love UE4 but is killing productivity.
I would recommend you start a new thread and not bring old thread back to life.
On a side note, my experience with 4.8.3 is far more stable then earlier versions and I hardly ever experience crashes. If you experience crashes, please submit them to Epic so that they can look at them and hopefully fix them.
I am closing thread as I would prefer you to start a new thread. Thanks.
