About RTP

[WAS]

Those are the minimum system requirements. It's the minimum *that will work*. Not the minimum we recommend, not the minimum for a pleasant experience. The RTP works very well on average-to-good hardware. I have an i7-2700k in one machine, that's an 8 year old CPU, and even there it's quite usable. It is not intended to create final render quality quickly, it's intended to create a good impression of the scene characteristics dynamically, in a minimum amount of time. And for this it works well on appropriate hardware.

We'll consider adding a note that for use of the RTP, we recommend higher-level hardware. But again even a desktop-level Ryzen 7 1800x or so will do fine. Hardly a high-end or costly CPU.

- Oshyan

Oshyan, you don't even have a recommended listed, so trying to argue that is moot. What is recommended? No one knows. Lol You all don't even know how TG runs on high-end machines let alone more mainstream machines.

Minimum requirements also require the software functions as intended. Minimum just means performance may be slower than recommended. Not that things will be effectively broken or features missing. And if so, it's mentioned, like GPU support on Adobe without supported GPU.

If it doesn't work on minimum system requirements as expected, your requirements are not correct / erroneous / misleading, etc, etc.

The fact you guys try and say the recommended system requirements are always top of the line computers no matter what year it is or no real changes to the software's renderer etc, is just negligent, and frankly shady.... The software runs the same as it did in the late 2000s. Same level of performance, and crashes. Even in 64bit. And these complaints of stability come from people on all ranges of PCs.

Would love to see people actually benchmark the RTP with the benchmark scene against standard renderer default settings. From talking with long time users that also don't use the RTP for the same reaons, as even mentioned to me, it seems comments here are more out of respect for the software. This IS a issue.

I was going to purchase TG recently when I got a G to start my life. But I couldn't justify it. No matter the machine, everyone has issues, and for me with plenty of time, render times aren't that big of an issue, but it's everything else. Development pace, arguing from staff that don't even understand the standards of things like system requirements (especially legally for a product license amounting to a long-term legal asset [when over 500 dollars in WA State and a lot of states]).

Just ugh. My current PC would be considered high-end for it's time, and even TG2 runs the same, in 32-bit. Is that because I'm not meeting the "Illusive Recommended System Requirements" for 2009 (this PC, built int he future, would be considered high-end, especially with it's turbo)? Lol

[WAS]

Two more tests on two different CPUs, by far more high-end than my own which only reaches a max of 4.2Ghz boost. Users/Machines are anonymous for this conversation.

[attach=2]
[attach=1]

And the other machine. This one the RTP seemed to have just crapped out and ruined quality from finished standard preview... (I notice this a lot too where quality gets worse after RTP myself on my machine too)

[attach=3]
[attach=4]

screen and project resolutions are different, but we can clearly, and reliably see, on 3 machines from mid-range to high-end, the RTP is... subpar, to say the least.... lol

[cyphyr]

You do know that you have to allow the standard preview to finish generating the terrain BEFORE you select RTP ... don't you?

[Oshyan]

Without system specs these comparisons are not very informative. But more importantly *this is not how the RTP is meant to be used*. It's not intended to produce final quality images, it is meant for rapid iteration on things like surface texturing, clouds, lighting, etc. It also requires terrain be generated to the desired (or equivalent) resolution beforehand, which these tests clearly are not showing.

So a more relevant test would be to record the total time to generate the terrain with the standard preview, switch to RTP, then add and adjust several surface layers, clouds, lighting to desired specifications, allowing the RTP to refine *only* to the point where you can evaluate whether the result in the scene is what is desired. Then compare the *total* time (probably around 5 mins) with the same steps, but doing a render for *every* scene change. That last bit is critical: without the RTP, to achieve equivalent or higher preview detail you need to do a full render *for every adjustment*.

We never made any claim that the RTP should produce the equivalent image to a render in a lower total time, it works differently, has different goals. Otherwise we might as well make the RTP *the* render mode, right?

- Oshyan

[WAS]

You do know that you have to allow the standard preview to finish generating the terrain BEFORE you select RTP ... don't you?

As noted, the RTP crashed and produced that effect in the last example off a finished preview. Clearly the rest are based on finished previews (non HD). And since the RTP is quicker if you start it without a finished preview it would only be helping the RTP time results even if falsified.

*this is not how the RTP is meant to be used*. It's not intended to produce final quality images, it is meant for rapid iteration on things like surface texturing, clouds, lighting, etc. It also requires terrain be generated to the desired (or equivalent) resolution beforehand, which these tests clearly are not showing.

No, it's not meant for rapid anything. Lol It's slower than the standard renderer for accurate results. Lol That just makes no sense.

So a more relevant test would be to record the total time to generate the terrain with the standard preview, switch to RTP, then add and adjust several surface layers, clouds, lighting to desired specifications, allowing the RTP to refine *only* to the point where you can evaluate whether the result in the scene is what is desired. Then compare the *total* time (probably around 5 mins) with the same steps, but doing a render for *every* scene change. That last bit is critical: without the RTP, to achieve equivalent or higher preview detail you need to do a full render *for every adjustment*.

Mind updating the Wiki with that in a step by step guide? That's not conducive with how it's been laid out to be used through the forum since release. That's just weird what you're explaining. Why would I do a standard render, than change the scene and and than only time a certain portion of the RTP? That's not right at all. A good test is a test of it's entire iteration process against a much higher quality render which will work far better for previewing any asset of a scene in any instance.

We never made any claim that the RTP should produce the equivalent image to a render in a lower total time, it works differently, has different goals. Otherwise we might as well make the RTP *the* render mode, right?

This is simply about time. When you can get final-quality approximated results with the standard render in much less time, what IS the point of the RTP? Please explain it explicitly in a scenario, because from discussion and experience, it's nonsense. RTP even with using the HD preview finished, doesn't provide accurate anything to judge any asset of the scene. Especially surface textures and clouds, like wth?

There is no point to the RTP, is what you're explaining. We all know the RTP produces weird effects, especially with clouds, and is no judge of the final scene and would be erroneous to work off of. So other than saying there is a "Real Time PReview" feature of the program for a selling point, what the hell is it for!?

[cyphyr]

I (and apparently many others) find it extremely useful.
I don't expect it to give a result that is the same as the render and as I said before I ALWAYS switch off either lighting, visible atmosphere or shaders in the preview (as I do in the standard preview).
I simply think you are not using it in a useful way.

For example using RTP:
I can preview clouds seeds at a rate of about 1 every second. That's way faster than the standard preview. I don't need it to finish rendering to final quality to see that the cloud is in the wrong place or is casting shadows in a good or bad place for my composition.
I can position light and sun to cast shadows exactly where I want them with near instant feedback.
I can gauge height very accurately far away from the world origin by changing the value of a surface shader altitude constraint. (actually this needs to be addressed as it should work globally ...)
I can preview population texture changes in near real time.

There are a ton of ways to use RTP that improve work flow and speed up getting the result I want that are way faster than the standard preview.

My systems are not particularly "high end" and are certainly nor state of the art (5 and 8 year old processors)

[WAS]

I can preview clouds seeds at a rate of about 1 every second. That's way faster than the standard preview. I don't need it to finish rendering to final quality to see that the cloud is in the wrong

Are you using it right? By your own words, and usage, we're waiting for the standard preview to finish before even starting a RTP. Lol So it's Standard / HD Preview time + RTP time. Your talking magic there. How are you previewing after 1 second when even on higher end machines it takes much longer (regardless of disabling atmosphere and lighting, though not sure why you'd do that for clouds)

I'd love for you to record a video demonstrating your usage. Cause even you explaining it, like Oshyan, it just makes it seem even more useless, especially with prerequisites just to preview when a standard, full, render, is quicker. Lol

I've talked to a few people that are relatively versed in TG and they don't use RTP for the same reasons. It's more just a gimmick. It offers little to the production process but wait time.

[cyphyr]

Because you don't need the terrain to finish generating to get full previews of atmosphere and clouds.

The whole point of a quick preview is NOT to see a beautiful final finished result. It's just to see if the cloud is in the right part of the screen. Why would I wait any longer than I need to see that?
The standard preview takes at least 20 seconds to get to a 20% level and even then I can't gauge if a cloud seed is working or not. RTP gets me the info I need way faster.

I think maybe we have different ideas about what a preview is and how it should be used.

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.

[WAS]

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

Yeah, a bit of a quirk, when a user clicks RTP, the preview should be paused for RTP to function. I've noted that before somewhere.

But than again, you're still using the RTP for clouds which doesn't give good lighting or shape results, which even I believe Oshyan or Matt said RTP isn't good for clouds currently and needs works. Few topics on how clouds are nothing like finished render, and another useless point of it's advertised use.

It's only misleading for clouds. And than again, you have more accurate results with a render which is quicker than the RTPs iterations, making it further useless when you can get a far more accurate model for less time then setting up the RTP.

And again, for surfaces, jagged textures lacking fine small scale detail is hardly a good representation. About as accurate for detailing as normal render. Again, making a crop or full render more beneficial. Especially disabling atmosphere or other effects.

[cyphyr]

I completely agree there is work to be done improving RTP on cloud shading and structure (particularly with v3 voxel clouds) but that is not to say that RTP is useless.

It just needs to be used in an appropriate manner for what it is and then it can be a very powerful tool greatly speeding up workflow.

Quick low res cropped renders have their place as does the standard preview, and refining a cloud will take many approaches (particularly if they are animated: )

I'm sure that future iterations of RTP will address many users concerns and it will continue to be a valuable tool.

[Oshyan]

It's strange you're asking if Richard is using it right when he clearly feels he's getting value out of it, and you don't think you are. Maybe consider whether *you* are using it right, given that other people *do* find it useful? As for the other people you've talked to who have similar issues, why aren't they posting here about their own negative experiences?

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.

There are couple notable issues with cloud accuracy in the RTP, yes, but it is far from useless for clouds. These issues of cloud lighting and shadow casting accuracy affect certain situations, and should be improved in the future. In the meantime, however, you can get a very good understanding of cloud depth, shape, and other aspects with the RTP, much faster than any other method, including low detail full renders. The same is true for surface shading, populations, and more.

I've recorded a video to demonstrate. I compare RTP to making changes and using low detail/resolution renders to view those changes, as well as to the regular 3D preview refining to a similar level of quality as RTP. I've tried to match the full render quality to roughly match RTP for fairest render times. Higher quality settings can give better results than RTP but take longer render time, making it even more slow vs. RTP. But as you'll see in the video (recorded on my 8 year old i7-2700k), the RTP is way faster for these kinds of things which, for me, are some of the main things I do in Terragen. It's hard for me to imagine that the kind of responsiveness you can see in the video is not useful to you or anyone else.
https://planetside.co.uk/files/videos/rtp-vs-standard-preview-vs-render.mp4

Sorry there are a few missteps in the video, wasting a couple seconds here and there, but I think it's pretty fair (given that half of my mess-ups are in the RTP portion ). And yes, I stopped recording at the end before the RTP was finished rendering, but I let it refine to what I felt was an equivalent visual quality to the regular 3D preview in the previous sequence, and a reasonable approximation of the full render quality in the first sequence. The point of RTP is not to get full, final render quality, it's to get a quick "good enough" impression to allow you to quickly adjust and tweak your scene, then do more limited full renders to get the final look.

Now as you know the RTP cannot generate displacement on its own. Therefore the efficient use of the RTP *does* suggest defining displacement as much as possible while using the regular 3D preview (with shading and atmosphere turned off), and switching to RTP for everything else. This still means it is useful for a lot, surface shading, atmosphere, objects, and lighting, if not more. The only thing it's really not good at is terrain shapes or other displacement. Once you generate the displacement, you can adjust most other settings with rapid feedback. And in the future we'll remove the displacement limitation too.

- Oshyan

[DannyG]

For whatever it's worth I do not use the RTP for the reasons listed above. Crops and test renders work better for me. I look fwd to the RTP's further development

[WAS]

It's strange you're asking if Richard is using it right when he clearly feels he's getting value out of it, and you don't think you are. Maybe consider whether *you* are using it right, given that other people *do* find it useful? As for the other people you've talked to who have similar issues, why aren't they posting here about their own negative experiences?

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.

There are couple notable issues with cloud accuracy in the RTP, yes, but it is far from useless for clouds. These issues of cloud lighting and shadow casting accuracy affect certain situations, and should be improved in the future. In the meantime, however, you can get a very good understanding of cloud depth, shape, and other aspects with the RTP, much faster than any other method, including low detail full renders. The same is true for surface shading, populations, and more.

I've recorded a video to demonstrate. I compare RTP to making changes and using low detail/resolution renders to view those changes, as well as to the regular 3D preview refining to a similar level of quality as RTP. I've tried to match the full render quality to roughly match RTP for fairest render times. Higher quality settings can give better results than RTP but take longer render time, making it even more slow vs. RTP. But as you'll see in the video (recorded on my 8 year old i7-2700k), the RTP is way faster for these kinds of things which, for me, are some of the main things I do in Terragen. It's hard for me to imagine that the kind of responsiveness you can see in the video is not useful to you or anyone else.
https://planetside.co.uk/files/videos/rtp-vs-standard-preview-vs-render.mp4

Sorry there are a few missteps in the video, wasting a couple seconds here and there, but I think it's pretty fair (given that half of my mess-ups are in the RTP portion ). And yes, I stopped recording at the end before the RTP was finished rendering, but I let it refine to what I felt was an equivalent visual quality to the regular 3D preview in the previous sequence, and a reasonable approximation of the full render quality in the first sequence. The point of RTP is not to get full, final render quality, it's to get a quick "good enough" impression to allow you to quickly adjust and tweak your scene, then do more limited full renders to get the final look.

Now as you know the RTP cannot generate displacement on its own. Therefore the efficient use of the RTP *does* suggest defining displacement as much as possible while using the regular 3D preview (with shading and atmosphere turned off), and switching to RTP for everything else. This still means it is useful for a lot, surface shading, atmosphere, objects, and lighting, if not more. The only thing it's really not good at is terrain shapes or other displacement. Once you generate the displacement, you can adjust most other settings with rapid feedback. And in the future we'll remove the displacement limitation too.

- Oshyan

Cyphyr is the one that said to pause it and the RTP will update, why that was mentioned, but as you said, pauses everything.

And using something correctly doesn't equate to opinion, Oshyan... By design and By opinion are two separate matters.

It's also very weird we are using hypotheticals like a users opinion of approximations (especially if they HAVEN'T rendered) vs the actual result. For example totally different cloud forms and lighting than in RTP, few topics/posts on that I believe and seen it myself. Users shouldn't be relying on these inconsistencies. Especially new users.

You have "Not for production use" on the PT but are totally fine with the effects of the RTP... Absurd.

[Oshyan]

I am telling you how it is designed to be used. I don't really understand what you're trying to say. And I think you are significantly exaggerating the issues with the RTP. There are some cases where lighting in clouds can be very different, but for most other things it is a very close approximation of the final render, which is what it is meant to be.

- Oshyan

[WAS]

I am telling you how it is designed to be used. I don't really understand what you're trying to say. And I think you are significantly exaggerating the issues with the RTP. There are some cases where lighting in clouds can be very different, but for most other things it is a very close approximation of the final render, which is what it is meant to be.

- Oshyan

For me, they are not that close of approximations, especially for quality of forms vs crop or full renders. And even getting to a finished RTP is super slow. Especially on clouds. Over twice to 4 times the render time of a render. It's not practical no matter how you put it or people on the placebo opinion effect see it.

By design I mean it's performance vs what's already there. Your example usages have issues that have been noted, and even I see commonly, and just to get to that state of functionality you babe a longer iteration process than a render.

Than, your only minimum requirements, put it to absolute shame. Waiting 7 hours for a RTP to finish to "start" working on a scene vs a 4 hour render, or crop or preview rendering at 2-30m depending on scenario. I'd be long done with my final clouds before the RTP finishes. Lol

Than you have no recommended requirements or conclusive hardware evaluation so any argument there is negligent.

I just want to see some improvements where they belong. Most updates add something.or improve standard / pt rendering elements such as terrains recently but RTP has largely left alone and suffers issues.

Like I mentioned PT is not for production which has far less issues and we'll documented ones such as water volume.etc, but the RTP which has inconsistencies or crashes has no such notes and is there as something to rely on. For new users this is just confusing, and even as a long time user.

Either hardware evaluation needs to be done (not a silly project render timing) and figure out a real target PC class or maybe work on improving this.

I know what it's for, and want to use it. But it's garbage. Clouds can be inconsistent and lighting and shapes surely aren't actually close approximations, and if certain instances can cause issues like you stated it just be assumed users will run into it... With no real documentation into it. It's also not good for textures and lacks fine detail or a real level of AA for approximations.

You have to understand the level of detail and realism I strive for which is why you will rarely see finished anything from me. So you should immediately understand my concerns.... especially when you start talking about approximations I am telling you are far from..in the same.ball park, but a foul ball.