About RTP

[Oshyan]

I recorded and posted a video which clearly refutes the "RTP is slower than render for feedback during scene development" argument. As for specs, we maintain an entire benchmark list so people can see what good hardware is for Terragen. I don't know what's "silly" about that.

If you or anyone else can enumerate clear, specific, and reproducible issues with RTP, either crashes, or major deficiencies, we'll look into them and resolve them when possible. Some limitations are more difficult to address due to the very purpose of the previews, which is to be faster than a render (which I've demonstrated is clearly the case). Cloud rendering and shadow accuracy is one of these problems, and if it was exactly as accurate as the final render, then RTP would be slower, but we'll work on a better approximation, I agree it's important. As I've said we'll also remove the need to separately generate displacement in the regular preview before using RTP. Other than those two things, and the lack of transparency - which will be resolved along with the same deficiency in PT soon - I'm not aware of specific, significant issues with the RTP now that it has manipulation handles for objects (in Frontier, soon to be final release).

If you're having performance issues, run the benchmark and let's see how your hardware compares. If it's at or near the bottom of the list, you just can't expect to have a great, fast experience, simple as that.

- Oshyan

[Dune]

You have to understand the level of detail and realism I strive for which is why you will rarely see finished anything from me

There have been quality renders posted by others, with great level of detail and accuracy, before RTP was even included in TG, so RTP issues should be no excuse not to post your work. Just try your hand at a complete (and utterly good) landscape and post your progress.
You don't háve to use RTP to get good results, you don't háve to use it at all. It's something in development, and will get better/faster/more reliable in due time. No point nagging about it. Feels like a personal attack on Matt's capabilities, which I highly praise.
I won't get into this discussion, but I wanted to say this.

[archonforest]

You have to understand the level of detail and realism I strive for which is why you will rarely see finished anything from me

There have been quality renders posted by others, with great level of detail and accuracy, before RTP was even included in TG, so RTP issues should be no excuse not to post your work. Just try your hand at a complete (and utterly good) landscape and post your progress.
You don't háve to use RTP to get good results, you don't háve to use it at all. It's something in development, and will get better/faster/more reliable in due time. No point nagging about it. Feels like a personal attack on Matt's capabilities, which I highly praise.
I won't get into this discussion, but I wanted to say this.

Well said Dune!
This thread is just the most useless bla, bla, bla I ever read. If someone likes RTP and find it useful then let them use it and be happy about it. If the RTP is slower than normal crop render than use that. And that should be the end of it. I have a bunch of things in TG that I do not understand or use at all or work slow. But then what? Should I attack TG for it? Nonsense. Especially if that thing is in beta/development. 

[cyphyr]

...
Also even when you are using a terrain you only have to let it finish generating ONCE. Then pause it and all surfaces and lighting updates pretty much immediately.

...
The regular preview does not need to be paused to work with RTP, in fact the Pause button will affect both RTP and non, so you *can't* have it paused if you want to use RTP. Switching to RTP will automatically "pause" the regular 3D preview activity and all resources are then dedicated to tracing rays in the RTP.
...

Sorry, my bad, corrected now in case future readers don't wade this far through the thread.
YOU DON'T NEED TO PAUSE THE PREVIEW.

[Oshyan]

To be fair Richard in old alpha versions it did make sense to pause the preview before switching to RTP, so you're probably just remembering that.

- Oshyan

[WAS]

You have to understand the level of detail and realism I strive for which is why you will rarely see finished anything from me

There have been quality renders posted by others, with great level of detail and accuracy, before RTP was even included in TG, so RTP issues should be no excuse not to post your work. Just try your hand at a complete (and utterly good) landscape and post your progress.
You don't háve to use RTP to get good results, you don't háve to use it at all. It's something in development, and will get better/faster/more reliable in due time. No point nagging about it. Feels like a personal attack on Matt's capabilities, which I highly praise.
I won't get into this discussion, but I wanted to say this.

That's not the point there.

The point is a Real-time Render Preview as seen with other software, etc, being improved upon for Terragen for better use. Like in my scenarios. I'd love to use it since the normal preview is a pain, and crashes TG often, so I often just have it paused. I would like to use it for quicker previewing of shaders and atmospherics, but it needs improvements.

That's all this is about but unfortunately it seems users more like to just embrace the software as is than look objectively at it for it's benefit and future. For example staff citing bad system requirements when the requirements listed are only minimum, and as per business standards, that means the software should work as intended, just not at the speed of recommended. But we don't have recommended settings, and what's always used is top of the line tech of that year, every year, since 2009. It isn't standardized in any sense and cannot be used against me. That's just negligent and insulting of staff. It has nothing to do with my system but the implementation of the feature. I've tested it on numerous machines, had others test it, and even tested it on a absolute powerhouse of a machine on the east coast used for production development in top-of-the-line software for film.

This is ONLY about areas of improvement. And there is room for improvement. Just trying to excuse things for peoples opinions of a feature is negligent. It's been benchmarked in various scenarios and isn't up to par with production process of me as a hobbyist (me) let alone others. These people don't want to tarnish their name here, or don't use TG for a host of reasons anymore and it's my goal to improve these issues to get TG out there again by having transparent discussion about features of TG.

And being torn down because of my PC which is LEGALLY [above] minimum specs provided by the software developers themselves is just insulting to me and you (Oshyan) shouldn't expect anything short of a fight/argument about it.

And Oshyan, your video is just a setup. You're using the base preview. Don't use it. Pause it. You just make a change and macro/click render. The actual render is your preview; that cuts out almost half the time. Additionally you're using lower quality settings than the RTP making the RTP look better. Clearly we'd use higher settings than the RTP can even achieve.

[cyphyr]

I don't think anybody has said that there is not room or need for improvement. We are just giving advice (personal opinion and experience) on how to best use it in its current state of development.

[WAS]

I don't think anybody has said that there is not room or need for improvement. We are just giving advice (personal opinion and experience) on how to best use it in its current state of development.

I get that. But opinion is entirely subjective... and when someone is specifically, from the get go, before even the issue is pressed, is refuting that opinion, it's just argument. Not constructive, and leads to fighting.

I know how to use the RTP. The quality and speed of the RTP is my concern.... as said numerous times...

I want to use the RTP over renders is the point, but at current state, I can just use the standard renderer for vastly superior results for actual approximations of a high quality render. Especially for fine detail and displacements which is a lot of my work. A notice a lot of peoples work (Ulco included) lack real surface detail and use distance and AA to mask this, but it's very obvious to me.

[Oshyan]

I have no idea what point you're trying to make about my video. I show timings for everything and I show the intended, actual, normal, effective workflow of the RTP. You let the terrain displacement refine to the level you want it, then switch to RTP. I *included* that time in my video, and RTP was still faster than regular preview *and* doing full renders. The reason I used low settings in the normal renders is to get reasonable render time. If I used higher settings, the render time would consequently be even higher (e.g. around 1 minute for a single image with v3 clouds with Defer Atmo on, albeit higher qulaity), so the comparison would be even more in favor of RTP. I really don't understand how you're not seeing what I'm seeing there.

The RTP is useful for a range of specific things, in fact for a majority of what many people do in Terragen. It is not useful for displacement work right now, I've clearly acknowledged that multiple times. But that is just one aspect of a Terragen render. It may happen to be *your* specific focus much of the time, and in that case I can understand RTP not being that useful *to you*. I've said as well that we plan to improve the displacement generation and interactivity there. So perhaps you should just wait to use RTP if your work is mostly dealing with adjustments to displacement. In the meantime many people find it useful, if not vital, and we've had some extremely positive feedback about the addition of RTP vs. the old preview, etc.

I'm also curious why you haven't run the benchmark on your machine yet.

By the way, people speaking up here with constructive criticism and suggestions about our software is not "tarnishing their reputation". We are happy to hear from these people, even those who no longer use Terragen and want to explain why. So until we hear from the people you claim to have spoken to, I'm just going to consider that point a lot of hot air. There's no good reason for someone not to post their their well thought-out, constructive thoughts and have discussion here about the challenges and issues of using Terragen.

- Oshyan

[Matt]

Hey guys,

RTP is not ready for previewing terrain displacements. Speed/quality comparisons for terrain displacements will clearly show a normal render to be faster for equivalent quality. I think we all agree on that.

The reason the RTP takes longer than the normal render is because it spends time anti-aliasing, and no amount of anti-aliasing can make up for a low micropoly detail level. If high micropoly detail is important in your test renders, you will not find the 3D Preview very useful in RTP or non-RTP modes at the moment.

The anti-aliasing in the RTP is non-adaptive, which is another reason why a full render can produce a higher quality result in a shorter time. Adaptive sampling will be added in future, and that will make it much faster.

I didn't see anyone acknowledge that the RTP anti-aliasing is much higher than an AA2 render. It's equivalent to AA6 with max sampling (slightly lower in earlier versions). If you wait for the RTP to finish then of course it will take longer than a test render at AA2, so it doesn't make sense to compare an AA2 render to a fully-resolved RTP render. But the point is: you don't have to wait for the RTP to finish if you are not interested in an AA6 render. And if you decide you want to see a higher quality, you can choose to wait to let it progressively resolve. On complex scenes you probably won't want to do this, but you'll be more likely to do this after we put in adaptive sampling because then it will have a similar speed to a normal render.

So, clearly RTP is slower for high quality renders at the moment.

The reason we have the RTP is this: In many cases it updates in a fraction of a second. Sometimes it takes longer, but it shouldn't take more than a few seconds to give you some useful feedback. Atmosphere, clouds, lighting, object texturing (and terrain texturing, although less detailed) are some areas where you can get some idea of the results of your changes much quicker than you can with normal renders. For low quality renders, the RTP is often faster. It depends on your definition of low quality.

If this level of quality is not enough for your purposes, I understand. RTP will need to improve before it can be used to effectively preview everything. I think it also depends on the complexity of your scene, and the crossover point at which normal renders are more useful than RTP previews might depend on your hardware, e.g. if both the RTP and the normal render are very slow for a particular scene on a particular computer, simply doing a test render is more likely to tell you what you want to know in a shorter time. I am not surprised there are some scenes where the stated minimum requirements are not enough to benefit from the RTP. But I believe that on simple scenes with atmosphere, clouds and lighting changes the RTP may still be useful. Am I wrong about this? If this really is not the case I am open to changing our minimum requirements and/or stating some exceptions for the RTP until we can improve them, but I would like to get more information about the hardware we are talking about and exactly what is happening when you try to use the RTP.

[WAS]

I'm also curious why you haven't run the benchmark on your machine yet.

- Oshyan

I have. I posted it on Facebook. Even did a 3D depth pass of it. I didn't post it here because you specifically targeted much higher class machines then your system requirements publicly released when asking for system benchmarks. You said I could still submit mine but didn't sound like it would matter or be looked at much. Another reason I have big issues with "Minimum requirements" and that's it, and than being criticized for what the company has put forward. I'm not sure if you're aware of the Vista lawsuits where they put out system requirements where it did not function as it should, and than didn't offer these people support simply citing their systems as outdated when the box clearly targets it. From a business stand-point, transparency of functionality, and liability, it should probably be looked into. Maybe a real hardware evaluation through a beta test to target minimum and recommended system requirements. Seems the benchmark period for TG4 didn't effect what's available at all.

I'm honestly tired of everything starting with "Your system barely meets minimum requirements" or w/e I'm just don't. I think I'm just too poor to keep up with terragen I guess. Was a mistake. Which is sad since I can go use Maya, Blender, UNREAL, etc and render shockingly amazing stuff in a fraction of the time. Just no real terrain generation. Oh well.

Hey guys,

RTP is not ready for previewing terrain displacements. Speed/quality comparisons for terrain displacements will clearly show a normal render to be faster for equivalent quality. I think we all agree on that.

The reason the RTP takes longer than the normal render is because it spends time anti-aliasing, and no amount of anti-aliasing can make up for a low micropoly detail level. If high micropoly detail is important in your test renders, you will not find the 3D Preview very useful in RTP or non-RTP modes at the moment.

The anti-aliasing in the RTP is non-adaptive, which is another reason why a full render can produce a higher quality result in a shorter time. Adaptive sampling will be added in future, and that will make it much faster.

I didn't see anyone acknowledge that the RTP anti-aliasing is much higher than an AA2 render. It's equivalent to AA6 with max sampling (slightly lower in earlier versions). If you wait for the RTP to finish then of course it will take longer than a test render at AA2, so it doesn't make sense to compare an AA2 render to a fully-resolved RTP render. But the point is: you don't have to wait for the RTP to finish if you are not interested in an AA6 render. And if you decide you want to see a higher quality, you can choose to wait to let it progressively resolve. On complex scenes you probably won't want to do this, but you'll be more likely to do this after we put in adaptive sampling because then it will have a similar speed to a normal render.

So, clearly RTP is slower for high quality renders at the moment.

The reason we have the RTP is this: In many cases it updates in a fraction of a second. Sometimes it takes longer, but it shouldn't take more than a few seconds to give you some useful feedback. Atmosphere, clouds, lighting, object texturing (and terrain texturing, although less detailed) are some areas where you can get some idea of the results of your changes much quicker than you can with normal renders. For low quality renders, the RTP is often faster. It depends on your definition of low quality.

If this level of quality is not enough for your purposes, I understand. RTP will need to improve before it can be used to effectively preview everything. I think it also depends on the complexity of your scene, and the crossover point at which normal renders are more useful than RTP previews might depend on your hardware, e.g. if both the RTP and the normal render are very slow for a particular scene on a particular computer, simply doing a test render is more likely to tell you what you want to know in a shorter time. I am not surprised there are some scenes where the stated minimum requirements are not enough to benefit from the RTP. But I believe that on simple scenes with atmosphere, clouds and lighting changes the RTP may still be useful. Am I wrong about this? If this really is not the case I am open to changing our minimum requirements and/or stating some exceptions for the RTP until we can improve them, but I would like to get more information about the hardware we are talking about and exactly what is happening when you try to use the RTP.

The AA doesn't appear to be near even AA2, realistically, when finished. Do you mean just texture space and clouds? Cause even that looks far sub-par to a standard MPD 0.5 AA2 render. Could you show specific quality examples at the same resolution? I would be curious to see. Cause the RTP, finished, on my system is a jagged mess of square edges... I'm sure using the HD preview before RTP would help there but I can't imagine it being much better. I'll test.

The issue with displacement, is it is PART of texturing, especially when using it to influence texture space, warp it, and evaluate shadowing and lighting within it displacement space. That's where it being advertised for surfaces is confusing to me. Maybe for 0.5 PF displacement detail surfaces with high min scale, it's great, but that doesn't make sense for most scenes when actually judging your shaders for a final render without having to be surprised and go for a round 2, 3 or 4 overnights. That's where I say just rendering out crops or full preview (full) renders if more beneficial.

And than with clouds, I consistently see issues with shadow intensity, and shapes, where shapes don't match, or it seems to just "miss" parts of the coud forms. Maybe this is another issue between HD and standard preview render before RTP.

Also occasionally, as noted and seen in a image here, sometimes the terrain will explode during a RTP and revert to like 5% normal preview or something like equiv of MPD 0.01 -- obviously without making any changes to the scene, it just happens mid RTP iterations.

[Dune]

I would be quite keen to see some of your non-TG work if you can 'render shockingly amazing stuff in a fraction of the time'....

[WAS]

I would be quite keen to see some of your non-TG work if you can 'render shockingly amazing stuff in a fraction of the time'....

My work in other software is texture work as I don't model (yet), such as making procedurals from TG. And currently just a in-dev game so can't share anything. This is one of the reasons I love TG over all software. The planet is my model.

But you don't need to make things yourself to run one of the hundreds and hundreds of pre-made scenes for benchmarking and education not to mention tech demos demonstrating features.

https://www.blender.org/download/demo-files/
https://docs.unrealengine.com/en-US/Resources/index.html
https://docs.chaosgroup.com/display/PHX3MAYA/Example+Scenes
https://simplymaya.com/maya-resources-free-downloads/
Etc

[Matt]

The AA doesn't appear to be near even AA2, realistically, when finished. Do you mean just texture space and clouds? Cause even that looks far sub-par to a standard MPD 0.5 AA2 render. Could you show specific quality examples at the same resolution? I would be curious to see. Cause the RTP, finished, on my system is a jagged mess of square edges... I'm sure using the HD preview before RTP would help there but I can't imagine it being much better. I'll test.

I've attached screenshots of the RTP at 10 seconds, 60 seconds, and finished. It's 16-core (32 threads) machine, but I'm attaching these just to show you what the RTP should look like. To get to a high quality it's slower than a full render of course. I think the 10-second RTP screenshot shows the sort of quality that I would be using to make decisions about cloud shapes and positions, general lighting choices, large scale surface distributions, etc. But updates are slower with heavy use of populations.

Also attached:
- full render at detail 0.2, AA2 with default AA settings
- TGD file

Are you able to get something similar? What does it look like on your machine?

[WAS]

That's not the default render settings, so of course would yield worse results... but of course an actual default render of MPD 0.5 AA2 looks much better throughout the terrain set. The clouds look alright on a the RTP AA, thought for some reason they look oddly warped like the aspect ratio is off on the clouds themselves. 

Interestingly, with the same exact settings, and seed, I do not get the same Easy Cloud forms as you do. Any other edits in other tabs? That's concerning to me for projects on other machines. I matched up camera view like you have it, so should be seeing the same cloud forms. 

And I do admit working with clouds is faster with RTP (mainly cause my CPU is just slower rendering V3 clouds in general for continuous full preview renders), but the interesting effects don't work in my favor. Also fully dark places look darker in the RTP similar to non-RTP shadows... and it's off by quite a bit, making it not a good approximation of shadows. Sure, their locations, but not intensity of your cloud fractal and density settings.

But over all that testing with RTP, I definitely feel I get the wrong impression, not a close approximation, of my clouds, textures, and lighting.

I guess it's just me.

I've also attached a image showing a MPD 0.5 AA2 and to me, it sure looks like AA in on par for clouds, and a full magnitude better for terrain forms and textures to provide actual approximations of lighting. Pay close attention to shadow AA and geometry within the highlighted area (among the rest of the image).

So, to summarize, I disagree on the quality of AA you claim still. If you did an exact export of the RTP, and than a same resolution standard rendered and difference them, there would be a whole lot of polygon and square shapes, that difference being from the lesser of the quality images -- the RTP.

Thanks for taking the time to make an example.