Started by WAS, July 17, 2019, 12:56:23 pm
Quote from: Oshyan on July 17, 2019, 03:51:18 pmWe are not able to reproduce this behavior nor have we had any other reports of it that I'm aware of. So we can't really diagnose it. Last we heard you were working on some comparatively low-end hardware so I'm inclined to think it may be related to that in some way. Please don't go into the minimum system requirements discussion again. We are working to provide better guidelines on that, but it should be understood that "minimum" means it is the minimum to run the software, not to have a great experience. Wikipedia puts it this way when talking about "recommended system requirements" vs "minimum system requirements":"Generally speaking, [recommended system requirements] is a better guideline than minimum system requirements in order to have a fully usable and enjoyable experience with a software."We do not yet have a "recommended system requirements", but we hope to create one.- Oshyan
Quote from: Oshyan on July 17, 2019, 04:25:06 pmYou're implying you have some inside knowledge about how we chose the minimum system specs, how we do testing, etc. Where do you get that knowledge I wonder? We're not Autodesk, with access to a full lab of computer hardware to test on, but we have a pretty clear idea of how Terragen performs across a range of systems.
Quote from: Oshyan on July 17, 2019, 04:25:06 pmAs far as testing other renderers, I'm not going to make any claim that Terragen is as good or efficient as a dedicated renderer like Octane. However unless your tests on any other renderer are with a similar scene, that includes dynamic/runtime displacement on a large (terrain-wide) scale for example, then the comparison is fairly inapplicable and doesn't tell us much about the source of the problem. Using a non-comparable test to imply some kind of root issue in Terragen's renderer isn't really useful.
Quote from: Oshyan on July 17, 2019, 04:25:06 pmKeep in mind I'm not saying there is no problem in the path tracer. I'm simply saying we haven't been able to replicate the issues like this that you are reporting. And unless we are able to do that, we can't determine the cause and fix any potential problems. So please do send us your file.- Oshyan
Quote from: Oshyan on July 17, 2019, 04:55:22 pmFiles received but are identical. Additionally, is path tracing supposed to be enabled? Because it's not. Maybe you sent the wrong files?P.S. The benchmark we released was not intended to be used for path tracing. That's why its setup to not use path tracing.- Oshyan
Quote from: archonforest on July 18, 2019, 06:40:11 amI think the minimum System CPU for TG is a quad i7 around and above 3Ghz. Preferably a newer generation. (Or an equivalent AMD). I actually tested TG on an i3-not latest, i5-not latest and now on a newer i7-6700. An i3 and an i5 can run TG of course but it is not productive at all. The earlier mentioned i7-6700 is kind of okay. You can get things done with it in a reasonable time. I think PS should not invest any time to test and test and test...with lower class CPUs than an i7 or similar AMD.
Quote from: Oshyan on July 18, 2019, 05:41:56 pmI have tested your scene with and without PT. While the camera-up version (that shows some sky) takes a bit longer to render, it is nowhere near the level that you reported. In non-PT it is 32m56s vs. 33m45s. In PT it's 5h36m vs. 7h59m. I am not certain of the reason for the difference but I would guess that the lower angle simply creates more interreflection that needs to be rendered, and that's the most intensive aspect of this scene by far. It also increases draw distance, showing the background mountains, as well as making direct atmosphere volumetric calculations necessary due to the visibility of the sky. All of these are understandable contributing factors to a longer render time.I also found that both scenes use 100% of the CPU for the majority of the render, only reducing slowly toward the end as the few remaining buckets are rendered by individual threads which are taking longer. This happens in your scene particularly around areas of interreflection which, as I mentioned, are the most intensive in this setup. This is clearly a very demanding and render time intensive scene with PT enabled. Matt has suggested that using the built-in displaceable spheres might be one factor in it being slower than it could be. So you might consider using an imported sphere instead. An upcoming update will have a built-in non-displaceable sphere that should calculate faster for situations where you don't need the displacement effect. I will also note that memory use can be fairly high on this scene, depending on the number of threads. On my system with 32 threads it used about 20GB when calculating scene 2, with the camera showing some of the clouds and horizon. I don't know what machine you're working on at this point, I recall you had only 4GB of RAM for a while, but hopefully you have a bit more than that now. Still, 20GB is quite a lot. The memory use will of course be less with fewer threads.As you can see this was tested on a high-end machine. But unless virtual memory or some other massive performance killer is involved, render time scales pretty linearly. You can clearly see this on our benchmark result lists. So obviously these renders would take a lot longer on your hardware, but the important thing I was testing here is whether the difference between the two camera perspectives creates an *unreasonable* difference in render time, and I have demonstrated that it does not, and hypothesized a plausible explanation for the difference that does exist.At any rate since I'm still unable to reproduce your reported problems I can only conclude again that some local, system-specific issue is occurring, such as VM paging to disk.- Oshyan
Quote from: Matt on July 18, 2019, 05:54:18 pmWAS, what was RAM use like when this happened? Maybe you were hitting VM hard and it was paging to disk?There are all sorts of reasons why hardware requirements can change depending on the camera position. If your scene does a lot of ray tracing between displaceable objects (e.g. interreflections), I am dynamically creating micropolygons in the subdiv cache to support this. So RAM use will vary. If you hit VM hard then it will slow down massively, and the solution might be to get more RAM. Does that mean the minimum requirements are wrong? I think it just means they won't be enough for everything you try to do, just like you wouldn't expect a renderer to be able to load bigger models than you have RAM for and wouldn't blame it on the minimum requirements. There are all sorts of scenes that weren't practical to render in 2009 but are now with better hardware.