Who uses RTP? How does it function for you? On my AMD A10-5800k it's useless. It takes far longer to render it's preview than an actual render takes. This seems to not be conducive with system requirements at all.
Additionally, what's it's real use being so slow over crop rendering? Only thing I really gather useful from it is cloud previewing, which is especially slow on my end. I could leave a RTP going over night and it won't be done with it's passes... while the render would be done over 3 hours.
Even on my Xeon it was too slow to use and never really understood it's implication vs the renderer.
As a note, this seems like a really good area to work on GPU rendering with TG. the GPU could handle this stuff like cake-work, and would make sense, cause I get additional crashing with GUI when using RTP and updates vs even the normal preview updates relying on CPU for both preview and computation in real time.
I can only agree with that!
It's pretty fast on my machine, but I only use it sparingly to check on procedural texturing on objects, and clouds, and sometimes the feel of an entire scene. Very useful for that! But I'm always afraid it'll crash TG when using it it all the time.
I use it all the time (check machine specs in sig) and find it very efficient.
I don't often use it for an entire scene though. Often only a cropped area and mostly surfaces only or atmosphere only.
Also in more complex scenes the preview may need to be re-set.
Not sure if it is using the GPU or CPU.
It's not too slow on my machine as well. I really like it and I use it more or less the same like Ulco and Richard.
I'm using RTP all the time and it's super useful for lighting/atmo tweaks. Previewing clouds is a hit and miss sometimes since the voxel cache is different (and a few other things probably) but in general it makes a huge difference for me and TG has improved a lot with RTP in my opinion. The only thing I miss is having terrain to recompute with RTP on, but that is being worked on IIRC.
As for CPU vs GPU, I guess porting RTP to GPU is quite an effort and it could in fact end up slower than CPU once it exceeds the GPU's memory. Also, supporting all the different GPU code ecosystems (OpenCL vs CUDA) and models is not trivial, and likely impossible for small dev teams.
I use it mostly for lighting and shader color adjustment, but on big scenes, it will eventually stop working and I can only refresh it by reloading the scene.
Would use it more if it was more reliable.
What might be more interesting is some way to lock down the 3d viewport displacement so it doesn't update all the time (with some kind of region padding so you could move the camera about a bit)
but don't know how possible that would be.
Quote from: pokoy on June 05, 2019, 07:56:49 AM
As for CPU vs GPU, I guess porting RTP to GPU is quite an effort and it could in fact end up slower than CPU once it exceeds the GPU's memory. Also, supporting all the different GPU code ecosystems (OpenCL vs CUDA) and models is not trivial, and likely impossible for small dev teams.
That's a pretty bold statement. GPUs, like CPUs, have logic for communication. OpenCL vs CUDA is just a choice. One is proprietary, one is not. They both communicate with the GPU. The difference here is CUDA can use multiple GPUs, OpenCL cannot (it doesn't know how).
Additionally, like any GPU/Game/Renderer, it doesn't need to rely on only it's GPU memory.
Which todays, coupled with it's GPU, is much more efficient than a CPU by leaps and bounds with not only iteration speed but memory usage, because it has dedicated on board memory, and the systems on board memory. Most GPU units people use for rendering are at 6-8gb coupled with 16-32gb RAM in the machine. Workstation GPUs come with far more ram such as the Vega coming out with 32gb for Apple's workstation.
For the work TG is doing, especially moving to PT, it only makes sense to move to GPU rendering like the big boys. CPU rendering at home was really a means to fill a void that SGI made with it's GPU rendering that wasn't available to consumers at home.
------------
I'm not sure what's with the RTP on my CPU than. It is absolutely worthless and doesn't follow the programs System Requirements of a Quad Core. My system is 3.7ghz base, at 4.2ghz overclocked. Should be fine. For example the "proudly CPU" based Corona is very stable and quick on my system.
GPU rendering on my RX 480 8GB however is vastly quicker than Corona or TG, and in many cases for far more detail in objects and geometry.
Quote from: WASasquatch on June 05, 2019, 11:13:59 AM
Quote from: pokoy on June 05, 2019, 07:56:49 AM
As for CPU vs GPU, I guess porting RTP to GPU is quite an effort and it could in fact end up slower than CPU once it exceeds the GPU's memory. Also, supporting all the different GPU code ecosystems (OpenCL vs CUDA) and models is not trivial, and likely impossible for small dev teams.
That's a pretty bold statement.
...
For the work TG is doing, especially moving to PT, it only makes sense to move to GPU rendering like the big boys.
...
Those big boys - chaosgroup, arnold, redshift etc - have teams of 10-20 and more people. TG would need to port every bit of the renderer - plus the entire node logic probably - to GPU. That's a task for an entire team and takes a lot of time. Not to mention the support demand for all the different problems that might arise from GPU model, driver issues, etc. I just don't think it's realistic.
Still, there's some impressive GPU render tech out there, and yes, it wouldn't be bad at all.
Quote from: pokoy on June 06, 2019, 07:39:05 AM
Quote from: WASasquatch on June 05, 2019, 11:13:59 AM
Quote from: pokoy on June 05, 2019, 07:56:49 AM
As for CPU vs GPU, I guess porting RTP to GPU is quite an effort and it could in fact end up slower than CPU once it exceeds the GPU's memory. Also, supporting all the different GPU code ecosystems (OpenCL vs CUDA) and models is not trivial, and likely impossible for small dev teams.
That's a pretty bold statement.
...
For the work TG is doing, especially moving to PT, it only makes sense to move to GPU rendering like the big boys.
...
Those big boys - chaosgroup, arnold, redshift etc - have teams of 10-20 and more people. TG would need to port every bit of the renderer
That's literally not an excuse. Matt is more than capable of hiring developers. It's currently his choice he runs the show as a two man group... Matt can do whatever he want, hold TG back, use it as a private income source for contracts, develop as a hobby, but it doesn't excuse the potential in the industry for other consumers that it could be. I've seen more complaint over the damn GUI in here than anything that's actually practical to the industry end-goals, unknowingly admitting their novice stance.
As is, the fact it's a CPU renderer limits it's use in film because of time constraints (literally from the babes mouth over why they moved to other software post pilot). SGI saw this issue decades ago and moved appropriately to hard GPU reliance (though in the late 80s when they were hard at research CPUs weren't practical for CPU rendering, even with mathcos, etc, even handling the hardware was hard which is why the MIPS was used for proprietary goals.)
Ideally you'd want to be able to make a low rez camera preview in RTP. That would be boss.
The GPU side of rendering is moving at warp speed. We are using octane on this job, and nearly ALL of our backgrounds are 16K sphericals that I make in Terragen. We've also used Gaea project data I've done on cards - single polys I might add - for amazing terrains with VDB clouds. Renders like lightning.
It seems clear that people are on just much to high-end machines to really see the issue, and more get a placebo effect.
On a machine that matches the system requirements for Terragen, the RTP is rubbish, and most certainly needs to be looked into. I'm honestly not sure why it was released without actually benchmarking it. In any situation I throw at it, it is much slower than the standard render, which is at much higher resolution and quality. See images.
Standard render is in MPD 0.5 AA 0.2
Just rendering for preview: 2.2m
RTP for preview: 3.8m (for a fraction the quality and smaller resolution...)
Each to their own way of working of course but I have never waited for a preview to finish.
Also I rarely use all three rendering modes (Shaders, Visible Atmosphere, Lighting) at the same time; mostly only choosing one.
It is after all "only" a preview and not expected to show an end result but rather give a good enough approximation to judge if a setting is working as desired or not (and there is room for improvement there I grant, particularly with clouds).
Quote from: cyphyr on June 08, 2019, 06:30:19 AM
Each to their own way of working of course but I have never waited for a preview to finish.
Also I rarely use all three rendering modes (Shaders, Visible Atmosphere, Lighting) at the same time; mostly only choosing one.
It is after all "only" a preview and not expected to show an end result but rather give a good enough approximation to judge if a setting is working as desired or not (and there is room for improvement there I grant, particularly with clouds).
Definitely to each their own. Hardly bothered to change the node setup or disable them to see. Usually their part of the preview. Many previews I do are not for a good enough approximation but actual quality control previewing. You can be very disappointed rendering a scene without actually testing it's high detail. Lower MPD settings won't give you a real idea of your surface textures a disp, plus lighting interaction.
This is not about what it's good for, but the fact it is not optimized for a full release. It is slower than the standard renderer, again, for far less detail. Definitely a QC area issue. Making it useless for practical use as it offers no actual benefit... Actually uselss. For a system in specs, over just rendering the whole thing or crop rendering. That's a quality and performance issue of the software.
It is not practical but to a high end user that wouldn't even tell the difference, which is why benchmarks exist.
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
Quote from: Oshyan on June 08, 2019, 07:34:49 PM
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
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
You do know that you have to allow the standard preview to finish generating the terrain BEFORE you select RTP ... don't you?
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
Quote from: cyphyr on June 09, 2019, 01:58:21 PM
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.
Quote from: Oshyan on June 09, 2019, 02:00:35 PM
*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.
Quote from: Oshyan on June 09, 2019, 02:00:35 PMSo 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.
Quote from: Oshyan on June 09, 2019, 02:00:35 PMWe 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!?
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)
Quote from: cyphyr on June 09, 2019, 03:35:13 PM
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.
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.
Quote from: cyphyr on June 09, 2019, 05:42:00 PM
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.
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.
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 :D). 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
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
Quote from: Oshyan on June 09, 2019, 06:46:13 PM
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 :D). 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.
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
Quote from: Oshyan on June 09, 2019, 08:48:37 PM
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.
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
QuoteYou 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.
Quote from: Dune on June 10, 2019, 02:21:47 AM
QuoteYou 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.
Quote from: cyphyr on June 09, 2019, 05:42:00 PM
...
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.
Quote from: Oshyan on June 09, 2019, 06:46:13 PM
...
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.
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. :D
- Oshyan
Quote from: Dune on June 10, 2019, 02:21:47 AM
QuoteYou 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.
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.
Quote from: cyphyr on June 10, 2019, 03:24:21 PM
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.
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
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.
Quote from: Oshyan on June 10, 2019, 04:33:58 PM
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.
Quote from: Matt on June 10, 2019, 06:39:30 PM
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.
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'....
Quote from: Dune on June 11, 2019, 01:18:57 AM
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
Quote from: WASasquatch on June 10, 2019, 10:23:11 PM
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?
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.
Quote from: WASasquatch on June 12, 2019, 10:39:08 PMSo, 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...
You do realize that anything using displacement is only derived from the OpenGL preview and does not use the same polygon detail that the final renderer uses? It's clear that RTP can't deliver the same displacement quality that way, and it is not meant to do so currently.
As for clouds, I partially agree. RTP clouds sometimes differ in density and most of the time shadowing and GI and thus the general look can look entirely different. This is by design, too, but I wish we had a way to tweak the way RTP degrades clouds. I would happily trade a few seconds of time saved in RTP for a result closer to what the final render looks like.
Still, RTP is invaluable to get the general shape and layout of clouds right, I can't imagine working without it anymore, it has save me hours of test renders on every single project.
Quote from: pokoy on June 13, 2019, 05:07:33 AM
Still, RTP is invaluable to get the general shape and layout of clouds right, I can't imagine working without it anymore, it has save me hours of test renders on every single project.
Oh yes!!!
Quote from: Hannes on June 13, 2019, 07:58:40 AM
Quote from: pokoy on June 13, 2019, 05:07:33 AM
Still, RTP is invaluable to get the general shape and layout of clouds right, I can't imagine working without it anymore, it has save me hours of test renders on every single project.
Oh yes!!!
echo!
Quote from: bobbystahr on June 13, 2019, 09:21:55 AM
Quote from: Hannes on June 13, 2019, 07:58:40 AM
Quote from: pokoy on June 13, 2019, 05:07:33 AM
Still, RTP is invaluable to get the general shape and layout of clouds right, I can't imagine working without it anymore, it has save me hours of test renders on every single project.
Oh yes!!!
echo!
Amen!!
Quote from: pokoy on June 13, 2019, 05:07:33 AM
Quote from: WASasquatch on June 12, 2019, 10:39:08 PMSo, 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...
You do realize that anything using displacement is only derived from the OpenGL preview and does not use the same polygon detail that the final renderer uses? It's clear that RTP can't deliver the same displacement quality that way, and it is not meant to do so currently.
As for clouds, I partially agree. RTP clouds sometimes differ in density and most of the time shadowing and GI and thus the general look can look entirely different. This is by design, too, but I wish we had a way to tweak the way RTP degrades clouds. I would happily trade a few seconds of time saved in RTP for a result closer to what the final render looks like.
Still, RTP is invaluable to get the general shape and layout of clouds right, I can't imagine working without it anymore, it has save me hours of test renders on every single project.
Than it is not as described. Rename it the
Somewhat Example of Real-time Cloud Preview.
It's not accurate for shadows and lighting, and It's not accurate for shapes a lot of the time....
And if it's not good for surfaces like explained is a direct use of it, in the beginning, that just leaves clouds. If it can't provide accurate shadowing and lighting for geometry it's innacurate, not an approximation. Inherenrly. So is it's only use is bare plains and very very distant mountains? Lmao
Why is it the nature of the RTP is being ignored for one little feature like a fucking cloud!? This is certainly not it's only use, from release, to now. And it inherently shouldn't be it's only goal or use, and most certainly can see improvement. Especially if we're already waiting on times beyond a standard render at MPD0.5 AA2. It'd nice to see improvement in processing time there too considering the base preview it's working off of is by magnitudes less detailed than the actual render. Why can't it apply the same logic in the renderer that takes far less time? Seems like things to think about to me. Always areas to improve and when things are like this, definite areas to improve. It's no question. Not a area of objective opinion. It's a design standpoint and you know what I'm talking about Matt.
Affirming reasons it should t have been released isn't helping any disposition. Especially the blatant ass kissing. Especially people that have admitted they don't even use the RTP in the past (Bobby).
Clearly the RTP. Changes the geometry entirely from.polygons to AA squares and is capable of much more. Erroneous shadows and lighting can't be by design or there is a serious lack of interest to realism and workflow.
Getting pretty pissed off to the ignorance to what's right in front of you in every image over a opinion of one little facet of the whole system
Matt / Oshyan I do not want any of my assets appearing on Planetside in any packages, and I'd like to know if you two would be able to remove my account and all posts at my in the future or if there would be issue?
If it is not as described then maybe the solution would be to give it a different description?
We have shown that it is useful, that it can give a good indication of textures and clouds in a VERY short amount of time.
If your complaint is that it is not as fast or as accurate as other software previews then although that may indeed be true and valid it still dose not take away the fact that it is faster than, and more useful than the standard Terragen preview.
Would you be happier if Planetside removed the name "Realtime" or "Texture", or "Preview" from its name?
It may not *technically* be a Real Time Preview but it is beyond me why you can't see that it is both useful and faster than the standard preview.
If you don't want to use it in the most efficient way then that is a limitation that you are imposing yourself.
Whilst one *can* compare elements of different software to each other I don't find it very productive. One is comparing things that are essentially different, apples with bananas, interesting but not particularly useful.
Definitely RTP is in need of improvement as is every aspect of every program. All software is in a constant state of evolution (except MS Word, that is just devolving back to primal soup).
It would be a shame to see you go, you have added a lot to our little community.
Quote from: cyphyr on June 13, 2019, 02:26:36 PM
If it is not as described then maybe the solution would be to give it a different description?
We have shown that it is useful, that it can give a good indication of textures and clouds in a VERY short amount of time.
If your complaint is that it is not as fast or as accurate as other software previews then although that may indeed be true and valid it still dose not take away the fact that it is faster than, and more useful than the standard Terragen preview.
Would you be happier if Planetside removed the name "Realtime" or "Texture", or "Preview" from its name?
It may not *technically* be a Real Time Preview but it is beyond me why you can't see that it is both useful and faster than the standard preview.
If you don't want to use it in the most efficient way then that is a limitation that you are imposing yourself.
Whilst one *can* compare elements of different software to each other I don't find it very productive. One is comparing things that are essentially different, apples with bananas, interesting but not particularly useful.
Definitely RTP is in need of improvement as is every aspect of every program. All software is in a constant state of evolution (except MS Word, that is just devolving back to primal soup).
It would be a shame to see you go, you have added a lot to our little community.
Speed would be entirely irrelevant if that results are not accurate, wouldn't you agree? Regardless of speed, if you relied on the RTP you'd have serious QC issues. That's just inherent to it's level of quality and how it draws shadows and lighting. You won't be rendering the same scene, especially on a detail level. So you
might as well just crop render to what you're specifically interested in seeing, which
WILL be faster than the RTP's iterations on top of the normal preview getting finished. Sorry, that's just how it is. And you'll likely be making changes to your scene causing the whole RTP to reset anyway (emphasizing cloud-only usage really). The only benefit is when it's done, but again the model has issues for actual approximation of the final scene, and your cloud settings, let alone all the surface lighting and texture issues which is one of it's advertised uses.
Well I usually crop the RTP area I want to preview anyway so no it wion't be faster.
I don't agree that the results need to be accurate. They need to be "good enough" for me to judge weather I'm going in the right direction or not and to do so quickly.
Accuracy comes later and then I will be doing crop renders.
For me (YMMV) the whole point of RTP is getting to a point quickly where I can start to use the full renderer and this I find it does very well. Hopefully in the future it will do it better :)
Despite our differences, I'd be sad to see you go given some of the nice contributions you've made here. But of course we can remove your account if you wish, and we won't post your assets (acknowledging that you are revoking permission recently granted). Your post content here would remain as it is in context of discussions that many other people participated in and, having posted it publicly, it is user generated content that is now part of the public record. All personally identifying information would be removed, of course. This is in compliance with current US and EU GDPR privacy standards.
Let us know if you'd like us to proceed with your account removal.
- Oshyan
Quote from: cyphyr on June 13, 2019, 02:48:44 PM
Well I usually crop the RTP area I want to preview anyway so no it wion't be faster.
I don't agree that the results need to be accurate. They need to be "good enough" for me to judge weather I'm going in the right direction or not and to do so quickly.
Accuracy comes later and then I will be doing crop renders.
For me (YMMV) the whole point of RTP is getting to a point quickly where I can start to use the full renderer and this I find it does very well. Hopefully in the future it will do it better :)
The RTP processing is inherently slower than the standard render, full or cropped. Lol been timed on many machines now. And still ignoring key points for opinions. Ugh.
Are you measuring until the render is finished?
Because I never wait that long for either RTP or standard.
Quote from: Oshyan on June 13, 2019, 02:50:14 PM
Despite our differences, I'd be sad to see you go given some of the nice contributions you've made here. But of course we can remove your account if you wish, and we won't post your assets (acknowledging that you are revoking permission recently granted). Your post content here would remain as it is in context of discussions that many other people participated in and, having posted it publicly, it is user generated content that is now part of the public record. All personally identifying information would be removed, of course. This is in compliance with current US and EU GDPR privacy standards.
Let us know if you'd like us to proceed with your account removal.
- Oshyan
You require a user signed T&C (of those conditions), which your conditions do not cover, in fact, they grant me full responsibility and ownership as author. The forum, staff, and owner, is not responsible and has no ownership of the posts.
Quote from: Planetside Forums T&CNote that it is impossible for the staff or the owners of this forum to confirm the validity of posts. Please remember that we do not actively monitor the posted messages, and as such, are not responsible for the content contained within. We do not warrant the accuracy, completeness, or usefulness of any information presented. The posted messages express the views of the author, and not necessarily the views of this forum, its staff, its subsidiaries, or this forum's owner. Anyone who feels that a posted message is objectionable is encouraged to notify an administrator or moderator of this forum immediately. The staff and the owner of this forum reserve the right to remove objectionable content, within a reasonable time frame, if they determine that removal is necessary. This is a manual process, however, please realize that they may not be able to remove or edit particular messages immediately. This policy applies to member profile information as well.
You remain solely responsible for the content of your posted messages. Furthermore, you agree to indemnify and hold harmless the owners of this forum, any related websites to this forum, its staff, and its subsidiaries. The owners of this forum also reserve the right to reveal your identity (or any other related information collected on this service) in the event of a formal complaint or legal action arising from any situation caused by your use of this forum.
Quote from: cyphyr on June 13, 2019, 02:54:16 PM
Are you measuring until the render is finished?
Because I never wait that long for either RTP or standard.
As noted over and over, quality is my concern, the whole point of actual renders. The RTP doesn't help with this process in it's current form. The basic previews locations of shadows and lighting is an approximation enough, the RTP doesn't help with actual cloud settings of density, and shapes within shadows to a real helpful degree, agian where you might as well just render a crop or full render, which will be quicker than the RTP iterations to completion (to a relative higher quality state), but again the difference is so negligible to the actual final product it's of no real help,
especially outside of clouds. Expecting users to not use a feature to completion because of an opinion of just stopping it when
you are satisfied is not conducive with the technical side and development, and especially other people where opinions are subjective.
I just did some RTP test on an I7-6700 cpu to try to understand what is problem here. Here is what I found out as a simple user:
- RTP is not very useful when u want to preview procedural content. It is slow and the picture is not really accurate. BUT it gives some data that might be enough for some people so they can see fast how things are going.
-RTP is very useful and very fast to view objects.
My scenes are obj heavy thus RTP is a blessing for my work.
Quote from: archonforest on June 13, 2019, 03:25:37 PM
I just did some RTP test on an I7-6700 cpu to try to understand what is problem here. Here is what I found out as a simple user:
- RTP is not very useful when u want to preview procedural content. It is slow and the picture is not really accurate. BUT it gives some data that might be enough for some people so they can see fast how things are going.
-RTP is very useful and very fast to view objects.
My scenes are obj heavy thus RTP is a blessing for my work.
I will agree heavily with objects. They look great, but they are just objects being rendered individually based on lighting environment. The non-lighted shaded versions in regular preview look great too, though. Just not the best lighting judgement at all.
You can literally crank down MPD and still have highly detailed objects lighted with a substantially lower render time.
For me, at least, objects render the quickest all around in TG because they are very pre-defined.
Quote from: WASasquatch on June 13, 2019, 03:13:15 PM
Quote from: cyphyr on June 13, 2019, 02:54:16 PM
Are you measuring until the render is finished?
Because I never wait that long for either RTP or standard.
As noted over and over, quality is my concern, the whole point of actual renders. The RTP doesn't help with this process in it's current form. The basic previews locations of shadows and lighting is an approximation enough, the RTP doesn't help with actual cloud settings of density, and shapes within shadows to a real helpful degree, agian where you might as well just render a crop or full render, which will be quicker than the RTP iterations to completion (to a relative higher quality state), but again the difference is so negligible to the actual final product it's of no real help, especially outside of clouds. Expecting users to not use a feature to completion because of an opinion of just stopping it when you are satisfied is not conducive with the technical side and development, and especially other people where opinions are subjective.
We seem to be going round in circles here .
Quality is your concern, it's not mine. Does that invalidate my opinion?
My concern is getting a rough approximation, which in my experience RTP does quicker that standard preview. Does that invalidate your opinion?
Given that we are using previews (both RTP and standard) for entirely different purposes it would seem unlikely that we will find common ground.
My current commission has over a hundred populations covering almost every visible surface in it and RTP can show me a a preview of anywhere on the camera path in a matter of seconds that is good enough to work from (and that is all I need). The standard preview just keels over and plays dead.
It's no more an opinion that it is working and useful to me than it is an opinion that it is not working as you would like for you.
Quote from: cyphyr on June 13, 2019, 03:55:24 PM
Quote from: WASasquatch on June 13, 2019, 03:13:15 PM
Quote from: cyphyr on June 13, 2019, 02:54:16 PM
Are you measuring until the render is finished?
Because I never wait that long for either RTP or standard.
As noted over and over, quality is my concern, the whole point of actual renders. The RTP doesn't help with this process in it's current form. The basic previews locations of shadows and lighting is an approximation enough, the RTP doesn't help with actual cloud settings of density, and shapes within shadows to a real helpful degree, agian where you might as well just render a crop or full render, which will be quicker than the RTP iterations to completion (to a relative higher quality state), but again the difference is so negligible to the actual final product it's of no real help, especially outside of clouds. Expecting users to not use a feature to completion because of an opinion of just stopping it when you are satisfied is not conducive with the technical side and development, and especially other people where opinions are subjective.
We seem to be going round in circles here .
Quality is your concern, it's not mine. Does that invalidate my opinion?
My concern is getting a rough approximation, which in my experience RTP does quicker that standard preview. Does that invalidate your opinion?
Given that we are using previews (both RTP and standard) for entirely different purposes it would seem unlikely that we will find common ground.
My current commission has over a hundred populations covering almost every visible surface in it and RTP can show me a a preview of anywhere on the camera path in a matter of seconds that is good enough to work from (and that is all I need). The standard preview just keels over and plays dead.
It's no more an opinion that it is working and useful to me than it is an opinion that it is not working as you would like for you.
There inherent goal of that closer approximation is through higher quality. I'm not sure what you're not understanding. There is already a rough approximation with the standard preview and added HD preview.
The goal of the RTP was not clouds, that's from the get go, but it seems the only real use if clouds, and object lighting I guess, but these are very exclusive items to the Terragen feature set, let alone it's intended goal in Terrain Generation.
Yes, you can move the camera with a population and some clouds. Is that it's goal? No, it's not. If you're actually working with your scene, making adjustments, than you're going to have to be regenerating that RTP. Terrain is the biggest thing in Terragen, though with V3 there seems to be a huuuge fad with clouds. That's great, we needed better clouds, but like holy crap. Lol
And yes we are going round and round, and it is because of subjective opinions and not a technical idea of the fundamentals of the system. I've said more than enough on the topic.