That is what would be my salvation. I am trying to do an overcast scene, with a finely displaced, slightly reflective ground, which in SR I would do by unchecking RT in the reflective shader. Only RT in the puddles, by decreasing the mask, very simple... and fast. But in PT, rendering comes to a virtual standstill over the displaced reflections on ground, whilst they needn't be very accurate and really reflective at all.
So, until I have a super computer, I have to either use no reflections, or use SR.
There's probably no way to overcome this, is there?
Wow, what a nice scene too.
Yeah reflections are a killer. Even without them and low lighting it can slow down on the ground cause of shadow bounce.
Looks good.
Ulco just curious if there would be any difference in rendering speed if you would export the ground as a heightmap and use that or export the ground as an obj file. Depends probably on the displacement, complexity of your ground.
That's actually a good idea. And you may be able to get by with low MPD and just subdivision it smooth.
Why would that be any different? You'd still have all the tiny reflections/shadows/displacements that need calculating from that heightmap. Or do you mean a topdown texture map rendered and projected onto an obj or heightmap? The workflow eludes me.
The ground is pretty flat overall, but has tiny displacements... and in the pit I need to make lateral (vdisp) 'outcrops' where shovels have cut the peat. They can't be baked into a heightmap anyway.
I was thinking of using the distort by normal feature to fracture a color, and have a bluish fractal with maximum slope projected on the dark ground, perhaps multiplied by a distance shader, so 'reflective' mud will be lighter towards horizon. Some pinpoints of light perhaps one reflective masked by diluted tiny fake stone, again multiplied by distance, but inversed for only reflective lights at front. Something like that, but I need to try still.
I was hoping it could be built into TG by Matt; a 'reflective' shader that does not calculate real reflections, but merely acts as a non-RT reflective shader in SR. Matt? ;D
Well heightmaps are far more simplified then a PF with low min scales usually unless you are using ridiculously high resolution. Same for objects and subdivision.
Also this is where a specular-only shader would, quite literally, shine. You could easily mock the dark color, even add some blue for environmental lighting if it was clear skies, and have speedy specular highlights. Heck could mix specular with high roughness spread and super low intensity with blue colour for environmental light. Still faster than then a reflective shader probably.
Back in the day ray traces reflections took ages and looked like garbage mostly (think that one deep sea movie The Sphere) so faking it was often better. In Jurassic Park for the T. rex debut, it was low lighting so easy to simply darken textures where wet, and use specular only. Boom. Wet dino. And still to this day looks fantastic.
I have tried reflection maping with a spherical render of the environment as texture; of course that's not accurate but it can work well in some cases. it would be nice if this were implemented in Terragen.
Thanks for the input guys. Mapping a spherical render is something I've heard/read about earlier, but takes an extra render first. I prefer one go, but it's worth investigating. It needn't be very high-res for just mud, I think.
I still don't get the heightfield thing. A heightfield is nothing more than a mapped displacement , IMO. If I need the tiny displacements, the map needs to be accurate and the displacements will still be minute and slow to compute. No difference. Or I misunderstand you completely, as I never work with heightfields.
It's the front area (first 10m) that gives the most slowness. Rest is covered anyway.
I have probably answered my own question. If you use the default shader and no fresnel reflectivity, but just metallic and some bluish color (or maybe a color map), rough ground PT renders very much faster than with real reflections, and gives pretty decent results with some fiddling.
The top one slowed down, so I stopped it after 15mins or so, bottom half would have taken much longer than that I gathered.
Looks usable Ulco.
I was curious and did a test with an exported landscape.
The OBJ file was 600 mb. It depends on your settings you know.
I tried to optimise and get rid of duplicate parts etc. but it took too long so i just threw the object as it is into the scene.
Normal Terragen scene without any object: 27 minutes
Scene with the ground obj file : 2 minutes and 32 seconds
The look is different and depends on the object, how you export etc. probably.
Interestingly the obj version looks like it does have more detail.
But other then that the render time difference is huge.
My Terragen version is old without pathtracer so i don't know how that would end speed wise.
Interesting. So you export terrain as obj, import as obj and apply the same textures as you would otherwise onto the obj? I have to go now, but will think of this method more. Thanks a lot, Kadri!
Quote from: Dune on March 24, 2021, 06:10:36 AM... So you export terrain as obj, import as obj and apply the same textures as you would otherwise onto the obj?...
Exactly. I use that same way in my animation that is rendering right now.
The main reason was render time but i hadn't tested it with reflection.
Does that mean that the tiny displacements you are seeing in your example is actually only bump, or is that real tiny geometry? If it's bump, I might as well project all my shaders onto an obj sheet, as the ground is pretty much flat, apart from the rectangular pit. I'll try that. It's a huge difference in render time indeed, and I gather from your information the long rendertime is from micropoly rendering versus the shorter time for obj 'bump' rendering. Very interesting.
No bump. It is all polygons.
Okay, thanks. So in fact I need a really finely displaced obj for the frontal area. I'm trying with a simple lowpoly flat obj atm. See how the bump comes out. The try and render an obj...
Quote from: Dune on March 24, 2021, 12:17:18 PM... If it's bump, I might as well project all my shaders onto an obj sheet, as the ground is pretty much flat, apart from the rectangular pit. I'll try that. It's a huge difference in render time indeed, and I gather from your information the long rendertime is from micropoly rendering versus the shorter time for obj 'bump' rendering. Very interesting.
But good that you asked. I accidentally used all the displacement from the original landscape on the object too, instead of only using the colour and reflection node. So the looks from the curious more detail was from there. Not sure if that detail was from displacement of the polygons or what not (maybe bump?)... But when i only used the colour and reflection node on the OBJ object the render time was even faster; 1 minute and 15 seconds. The image looks nearly the same as the standard landscape too now.
Curious if pathtracing will be any different on your test.
Yes, that figures. Perhaps the calculation of the bump on obj will take just as long as calculation of real micropoly displacement. In that case a fine obj is needed indeed, for just color projection. I'll do some experimentation.
And yes, PT is what I intend this for, because SR renders pretty fast, even with the small displacements and reflections.
Resolutions of heightmap and objects is waaay less detail than an actual TG terrain. This is why secondary displacement doesnt play well with erosion shader, or imported heightmaps because the actual subdivision of the area doesnt have as much detail. Ive mentioned this for years that using heightfield generate on a scene renders much faster than default terrain. But that's because its simplified and you can see that trying to do lateral displacement or heavily changing up the displacement
Quote from: WAS on March 24, 2021, 01:37:24 PMResolutions of heightmap and objects is waaay less detail than an actual TG terrain. ...
Yes. That was the reason i was surprised to see more detail in the OBJ scene. My fault...
This is the proper version here. But as i said this time the obj landscape rendered even faster.
Standart: 27 minutes 33 seconds
OBJ : 1 minutes 16 seconds
Even the bad lined rendering part in the middle is the same this time.
Im doing a pT test with heightmaps here. Currently timing TG terrain.
Time difference is in the quality with heightmaps, so may not be the best method. Obj seems quicker.
What were the render times and resolution of the heightmap?
Did you used it as a heightmap? There could be some fractal detail if so...
How about using it only as an image displacement?
That is true. I did not save it. I just let TG take control of the 10k area as a 1000 point heightfield. Ita bakinf a 8k heightmap so ill save that and try it as a image.
I tried saving the simple 8196x8196 10k area as a EXR, but it just loads as black terrain, or as fed to a displacement shader, no surface, just sky... Tried playing with disp and offset with surface layer, dunno what's up.
Starting to think something is wrong with TGs EXRs and may explain my opening issues and stuff.
I just thought about it a little. I don't know what the result will be with your next test Jordan.
But as Ulco said in the post in the first page maybe the difference is in which way Terragen renders micropoly detail and the other kind of objects.
If so, using heightmaps and or image displacement maps will only get a boost from using less detail and less number of nodes in the scene. It might be faster but maybe not as fast as using an object.
Curious...
Quote from: WAS on March 24, 2021, 03:44:18 PMI tried saving the simple 8196x8196 10k area as a EXR, but it just loads as black terrain, or as fed to a displacement shader, no surface, just sky... Tried playing with disp and offset with surface layer, dunno what's up.
Starting to think something is wrong with TGs EXRs and may explain my opening issues and stuff.
Hmm...sucks. I can't help too. I can not use pathtracing...
It's faster because of the detail of the mesh of the planet at the heightfield area.
As I've stated several times, you could have hundreds of shaders slowing TG down, or just a few, but as soon as it's a heightmap and simplified, it's far faster. At the cost of geomerty detail. Hence adding displacement, or lateral dispalcement, etc, is just a mess of folds and tears. Applying displacement to Classic Erosion of Heightmaps is a pain.
PS loading a ter seems to work fine but not sure of impact. Rendering now.
8196x8196 points at 10000x10000m as a TER is faster than 1000x1000 points at 10000x10000 meters (as a generate), however it seems to interact with the shaders strangely.
Still no [real] detail from original terrain. Trying smaller 1000 area now.
Definitely gets slower once you start approaching the detail of the original terrain. I'd say this is a little over half quality of the original terrain, and render time shows it.
With objects, there is no adaptive terrain, and other stuff effecting things, so I can see why they are even faster than a heightmap.
This is now a 8196x8196 at 1000m instead of 10000m. Shaders are culled to displacement so you can see where they end now, but in full scene that area could be easily hidden. It offers some render performance gain at the clear cost of quality. So a obj may be better unless further away from the focal.
Quote from: WAS on March 24, 2021, 03:49:14 PMIt's faster because of the detail of the mesh of the planet at the heightfield area.
As I've stated several times, you could have hundreds of shaders slowing TG down, or just a few, but as soon as it's a heightmap and simplified, it's far faster. At the cost of geomerty detail. Hence adding displacement, or lateral dispalcement, etc, is just a mess of folds and tears. ...
Eee...i said the same. I tried at least... "using less detail" should have been "from having less detail" in my post...
I should sleep. See you later.
Quote from: Kadri on March 24, 2021, 04:18:41 PMQuote from: WAS on March 24, 2021, 03:49:14 PMIt's faster because of the detail of the mesh of the planet at the heightfield area.
As I've stated several times, you could have hundreds of shaders slowing TG down, or just a few, but as soon as it's a heightmap and simplified, it's far faster. At the cost of geomerty detail. Hence adding displacement, or lateral dispalcement, etc, is just a mess of folds and tears. ...
Eee...i said the same. I tried at least... "using less detail" should have been "from having less detail" in my post...
I should sleep. See you later.
Well Ive said that since the get go, so I am not sure what you meant beyond what Ive already said here and in other topics.
The main thing was that Terragen renders micropolygons and objects different in my post.
Anyway...
Using objects looks better then.
Yeah I mentioned it's probably best.
If you subdivide enough too you could probably also use force displacement to doctor it
Thanks for diving into this. It doesn't seem that straightforward. I found that rendering in PT of the same textures on a flat imported extremely low-poly object takes about just as long, even if the displacements are then only bump. TG still needs to calculate the light and bounces, I guess.
For my scene only the first 5m or so are very slow, so I should make that area into a very finely displaced mesh. Or sculpt something like it in ZB. But actually, that workaround might take more active time than just have it render.
Or maybe rotate the camera 180º or do it in crops.
Or just work in SR. It needs to be a series of low paid 6000x4000 renders, so I'm not looking forward to a week of rendering.
Or perhaps make the ground drier.
Still curious if an exported object would be faster or not. Your test does have displacement made with Terragen going on.
Not saying that it would be faster but your test is a little different.
The foreground is just tiny displacements, like soil, so a sculpted plane in hires might be just as easy to import. Rather than having to export an obj. Dip the planet ground a bit and have the object fit into that place, add just textures... render. I might give it a try. But actually, I can't imagine it would be much faster, as the reflections on that sculpted obj still need computing across the slopes and angles... So why your test gives such a difference in rendertime eludes me.
Quote from: Dune on March 24, 2021, 05:26:59 AMI have probably answered my own question. If you use the default shader and no fresnel reflectivity, but just metallic and some bluish color (or maybe a color map), rough ground PT renders very much faster than with real reflections, and gives pretty decent results with some fiddling.
The top one slowed down, so I stopped it after 15mins or so, bottom half would have taken much longer than that I gathered.
That's an interesting discovery! I would expect metallic reflection and Fresnel reflection to render in similar times if they are made to be fairly equivalent. Fresnel puts more weight on glancing angles so it's difficult to make the metallic equivalent in that respect, but I wonder if you have the same settings for roughness. With high enough roughness it should be as fast as diffuse. At low roughness (between 0 and 0.2) the render times can vary quite a lot depending on the roughness.
For your "real" reflections are you using a Default Shader there too? How different are your two setups in terms of nodes used and the way they're connected? Can I also ask why you chose to make the metallic reflection blue? I assume your Fresnel reflections were not coloured this way so I wonder why you wanted to do that for the metallic.
Thanks for chiming in, Matt. I indeed found that with smaller roughness, render time increases. I will set up another test to see what I actually did, and post it.
No, the 'real' reflections are by reflective shader, masked by a reduced PF mask.
I made it blue to have a blue-sky-like reflection, multiplied by a distance shader, so it's bluer (more blue) near horizon. But that was before I added the clouds, so in fact it doesn't make sense anymore.
I did a new series of tests, but the outcome is now pretty much the same for all versions. I don't know what was the culprit of the slow render in the first few tests (I didn't save those). Perhaps the roughness was very small and masked by tiny fractal, and/or (and I think that's a more logical explanation) the shadows were soft, and the clouds heavier, with more AA (6, instead of 3 in these tests). I might try reconstruct that again...
Anyway, I think it's good to know that for mud a higher roughness is good (0.2-0.4)
Here's the tgd as well, for those of you interested in testing some more... (has some nice stones too)
Any luck with a real object test?
No, I haven't tried yet, and maybe I won't if I can get reflections to render faster.
I see.
If the free version behaved friendly i would have already tested this.
I thought Matt would say maybe something but no luck.
Have you tried playing with your min scales of all PFs and stuff to get a sweet spot so renderer isn't working so hard on bounce angles? I did a couple tests and raising min scales on my project shaved 3 mins off from 9 down to 6 minutes. Try and find a sweet spot where things more or less look the same, and try timing it.
@Kadri, your results agree with my expectation that an imported OBJ without displacement renders much faster than an object with dynamic micropolygon displacement. One the big expenses in rendered displaced surfaces is calculating ray intersections with micropolygons (for displacement), and this is more expensive whenever you have the unfortunate combination of (1) the rays travelling widely varying directions as they do when reflected off a rocky surface and (2) low roughness setting on the reflective shader, which doesn't let the renderer make any approximations that could make it faster. When you use an imported OBJ with the displacement "baked in", the ray intersector simply intersects static polygons, and this is much, much faster.
However, if you have displacement shaders applied to the imported OBJ (which will be rendered as bump mapping), they can still contribute to render time because they are evaluated when rays hit them. If there are many expensive displacement (bump) shaders applied, it could turn out that the OBJ takes longer to render than the original displaced micropolygons. That's because the micropolygons cache the results of the displacement shaders (up to the capacity of the Subdiv Cache) - i.e. the micropolygons are displaced already - and the displacement shaders aren't evaluated each time the micropolygon is hit by a ray.
Quote from: WAS on March 27, 2021, 02:10:13 PMHave you tried playing with your min scales of all PFs and stuff to get a sweet spot so renderer isn't working so hard on bounce angles? I did a couple tests and raising min scales on my project shaved 3 mins off from 9 down to 6 minutes. Try and find a sweet spot where things more or less look the same, and try timing it.
If you're working with shaders that respect the Smoothing Filter Shader, attaching one of those at the end of your chain should give you the same speed benefit, and then you only need to change one shader.
Oh yeah, that's right. Similar to my detail culling thingy I shared awhile back.
That actually may be a good idea too, add a distance culler, and use a smoothing filter fore the background area outside the foreground for a even more simplified setup than what's present. From my tests it can save anywhere from a minute to minutes depending on shader complexity.
Conversations like this have made be come to the conclusion that PT scenes require a little different planning in the workflow and making sure things aren't too needlessly complex (geometry wise).
Matt thank you for the detailed answer.
Just one more question just to be sure. I did this test in the old version but i suppose the same is valid for the pathtracer ?
Quote from: Kadri on March 27, 2021, 06:48:28 PMMatt thank you for the detailed answer.
Just one more question just to be sure. I did this test in the old version but i suppose the same is valid for the pathtracer ?
The Path Tracer uses ray tracing to do many things that were handled by the GI Cache in the Standard Renderer. Since you have a scene where the baked OBJ renders faster than on-the-fly micropolygon displacement, then the difference might be even more pronounced in the Path Tracer. But that's not necessarily the case in all scenes. The Path Tracer has many "optimisations" to improve its speed, and many of these optimisations don't work in the Standard Renderer or are not applicable there. The Path Tracer also forces the renderer to use deferred shading (unless ray trace everything is checked), so a direct comparison with the Standard Renderer should take that into consideration.
So, despite my not-so-bad outcome of the second tests, this proved to be an interesting thread. Thanks Matt, Kadri and Jordan! I knew of the smaller detail costing time of course, but didn't realize it, and the one final smoothing filter is a good idea. I already used it for water in the distance, but forgot again :P
Quote from: Matt on March 27, 2021, 08:00:05 PMQuote from: Kadri on March 27, 2021, 06:48:28 PMMatt thank you for the detailed answer.
Just one more question just to be sure. I did this test in the old version but i suppose the same is valid for the pathtracer ?
The Path Tracer uses ray tracing to do many things that were handled by the GI Cache in the Standard Renderer. Since you have a scene where the baked OBJ renders faster than on-the-fly micropolygon displacement, then the difference might be even more pronounced in the Path Tracer. But that's not necessarily the case in all scenes. The Path Tracer has many "optimisations" to improve its speed, and many of these optimisations don't work in the Standard Renderer or are not applicable there. The Path Tracer also forces the renderer to use deferred shading (unless ray trace everything is checked), so a direct comparison with the Standard Renderer should take that into consideration.
Thank you Matt.
Ulco not sure if you mean that by "smaller detail costing time". But it is not clear cut only that from what i understand.
Even a very detailed obj would render faster most probably because of the way the micropolygon and objects are handled differently.
As Matt said, probably the best basic way to put it, is that an object is actually a baked-cached version of the displaced ground.
That is clear for the old renderer, but a test would be good-needed for a direct comparison with pathtracer.
I understand that the smaller the detail, the more reflections cost (in time). I'll try a test of an obj with baked small displacements...
Curious how it will end.
By the way,
@Matt i tried with a very big OBJ file (15 Gb) i exported from Terragen.
I haven't used such a big obj file until now at all.
But while importing i got a similar error like Jordan got while importing big EXR files that it couldn't find that file.
Could there be a similar 32 bit limitation problem with the obj importer?
I wanted to exaggerate and test the scene actually.
But after the problem i mentioned above i used a smaller file.
I used a nearly 4 Gb obj file and Terragen didn't care at all.
It was still lighting fast (1 minutes 12 seconds).
The obj file before was 600 mb.
I've made a 1x1m sheet with small displacements (still a 70MB tgo), popped in front, and am rendering now. See what happens...
EDIT: First rendercrop of the object pop with fresnel reflectivity rendered in 12mins, and didn't look very nice. A render under same conditions but with planet displacements (and just metallic) took even less (9m) and looked good. Now one with real reflective is rendering, so let's see...
Quote from: Dune on March 28, 2021, 10:09:40 AMI've made a 1x1m sheet with small displacements (still a 70MB tgo),...
Did you add any displacement on the OBJ after you imported it?
It should only have colour and-or reflectivity for a real comparison.
No, I just fed the color (world space) into the default shader color input and set reflectivity. So, actually, my result contradicts yours ???
Hmm...Interesting.
I think i will take the annoying decision and install the free version and test this myself too.
Too curious to not to try...
Ulco i use this free-version for the first time and don't know the new features much.
I tried just to use the same file i made with my own old Terragen version and changed only to path tracer (25 landscape).
I can render only half HD of course but that doesn't matter.
I don't know how you test your scene but in this one the difference is still there.
The scene with the obj (600 mb) imported (by the way this free version couldn't even load the nearly 4 gb obj file)
rendered in 1 minute 8 seconds.
The standard fake stoned landscape is at 10 minutes now and still rendering.
So i think the difference is still there if i didn't make anything wrong and-or everything with the setting i made-use in the free version is right.
I used the reflective shader node.
I will try when the render finishes with the default one too ones again.
Wow!
If this test is correct the Path tracer is really slow with reflection.
It took 31 minutes 06 seconds to render in half HD. More then 4 times slower probably then the old renderer.
At least in this scene of course. I would export my landscape and render the scene only as all objects with the path tracer.
I couldn't get some useful reflection out from the default node as it is different-new to me.
I am making a new render with a new reflective shader node as it looks like there are quite some differences.
I used the old reflective shader in my test before.
The scene with the new reflection shader took 25 minutes 50 seconds to render.
This is a little faster but still hugely slower then 1 minutes 19 seconds with the obj object.
(The small longer time in the obj test is probably from GI. I used higher settings)
If this is consistent in general i would use objects for reflection so much i can.
A small test without reflection with the path tracer looked ok to me.
No such big difference. But this is the first time i try this new version.
I haven't been able to test cause TG isn't giving me any render elements, but I had an idea.
Use the specular / reflection outputs from standard render to composite in, or use them as a mask to fake with simple shapes. Depending on where your sun and lighting is it could be just three soft SSS shapes. One dark blue for away from sun, one light blue for focal center (if sun isnt center), and one white for specular on sun side. In PT it would render as fast as any texturing, and may look realistic. Could also project standard reflections with same images converted to masks within TG instead of composite.
From what I see in PT with empty sky, or overcast, the reflection is so simple it seems time is being wasted big time and could just be soft gradiented colours.
So it is faster, but the through camera projection doesn't match the scene, I don't know what to do about that. I'm not too familiar with the through camera projection, but to my assumptions it should match the scene if the camera isn't touched. Huh.
The outputs are as to be expected, specular, and reflection, and could be easily composited onto a PT render if need be on a reflection-less muddy ground. As for in TG itself from these images, not sure why they don't match up.
Add ref images, note the layer elements are from EXR so way brighter than they should be as JPEG.
If we could get help on why projection is wrong, this could really help. The Standard reflections take an hour, PT take 4 hours, and look almost the same for flat ground. And the compiled PT with projection only takes 12 minutes.... soo yeah, huge savings. But the alignment issue...
Looks good.
Try this if your scene is in HD.
("Fit mask to this" checked or unchecked didn't changed anything. It is just a leftover...)
Looks like Terragen expects a 1:1 image.
You have to calculate the ratio of the length and high.
If you have trouble just use something like this for testing.
Oh, that actually kinda makes sense. Didn't even think of that.
Here is a projection at aspect ratio 1 compared to original SR render. SR took little over an hour, PT took 23 minutes, which would probably be about 4 hours with reflections.
Gotta play with gamma of the convert to grayscale mask, and gamma of the reflection maps, but it works. I didn't really compare while changing gamma so probably not exact. I do notice a little bit of breakup in PT but that could be the noise from the renderer only at AA 6 (or the mask roughness and intensity from original SR render). Also just applied as a child of a surface mask. I wonder if a merge shader and using mixer would provide better results similar to masking surface shaders to not have a seam showing base colours along mask boundaries.
So you made a SR render layer with just reflections direct/indirect, used that as mask to project generic gradient across PT ground? I have to try that as well.
Meantime, I've done some more tests with several ways of getting a fast reflection on mud. Here are the results. Again, the roughness is the important factor. Above 0.2 it renders much faster, whether it's only metalic, or reflective.
Ulco can you post the scene you use above. Or anything we can test together here to get a better understanding?
It's on page 3: https://planetside.co.uk/forums/index.php/topic,29012.msg286160.html#msg286160 (https://planetside.co.uk/forums/index.php/topic,29012.msg286160.html#msg286160)
Hmm...The polysphere or whatever is a new object i think. I don't get that in my old version.
The newer versions of Terragen are now quite different then the older ones.
In the past you got errors but it rendered mostly.
I am trying to change the scene with the free version to be able to use it with my older one.
But it is harder. There are parts that makes Terragen crashing (my old version).
Yes, polysphere is new, sorry about that. But it's a very basic file, so you should be able to translate it to your version.
Couldn't make a closer look i wanted and got only this Ulco.
A direct comparison is not quite possible but still could be useful maybe.
This is an exported object from my old version and rendered in the free new version with the Path tracer (25 landscape).
I tried to use the reflective shader before and there was a huge difference.
This time i used only the default shader with your power f. nodes.
Render time is 1 minute 32 seconds (1280x720 MPD 0.6 AA 6).
It won't be a direct comparison but curious how long your normal scene would render with this default shaders.
If you want to try this, use this for the object and for the ground together (my scene you see here is only one object) and with AA 6 .
My test was actually just projecting the outputted direct and indirect EXRs on a the same terrain but no reflections. Just child layers masked by same image in grayscale with gamma adjustment on it with colour adjust. Also adjusted gamma on the EXRs themselves as they kinda apply dark for some reason.
What should I use for the object? There's nothing in your post.
I'm rendering something now, but will post results tomorrow (dinner time). I managed to export a 500MB terrain, import it, so that works at least.
I used default terrain, no object. A reflection-less ground renders speedy in PT. I think with the object version the idea is to apply the same shaders you'd use for the original ground and should have savings based on the set geometry
Quote from: Dune on March 29, 2021, 12:44:47 PMWhat should I use for the object? There's nothing in your post.
I'm rendering something now, but will post results tomorrow (dinner time). I managed to export a 500MB terrain, import it, so that works at least.
There is a tgc file.
Okay, I'll check that out first. What I did yesterday is point an orto cam down on an area just in front of the main cam, kill all lights and atmo, render to dsik after setting micro export. Turned out I still had the stones and wrong cam, so a piece of geo was a 'strip' towards horizon, with all polyspheres also present. I'll have a better go today.
@WAS , yes, without reflections a piece of ground renders pretty fast, but I was initially deterred by the long rendertimes due to (I think) low roughness (<0.2) reflective ground. And that is not necessary after all. But anyway interesting to see how exporting works, and whether rendering indeed speeds up over an obj.
Also interesting to be able to sculpt additional stuff into the geometry, which might be needed for some work.
I rendered an object at mpd=1 from the main cam (crop of front area) in 3mins, but the file is probably too big; 3gigs. If I load into TG, it says; can't find file. But I can get inside. So I don't know what's happening, but I'll try a smaller file size.
Thats the issue I am having with stuff over 2gb. Matt says he is fixing that though.
I forgot about that. But now I've made a smaller crop of 250MB, which is now imported and rendering. But it's not as simple to just feed all shaders into the color input of the default shader, as the reflections won't be covered. It needs more work to get a real comparison between microply render and obj render. For now I just added a reflective shader at roughness 0.1 and see how fast that goes.
Ulco as i said in Jordan's thread. For this workflow it is best to prepare accordingly.
I am making the real texturing (without any displacements) after i import the obj landscape.
But there are possible different ways like Chris used in his tutorial (exporting the textures of 25 tiled renders https://www.youtube.com/watch?v=ALbWYn_YHMI).
For another example, you could render a normal perspective render with the scene without reflection and use that for the imported ground then added with reflection as a camera front projection. You would get the same texturing plus reflection.
But if this is suitable and worth this hassle and time depends on you.
Thus the reason i said i use this mostly for animation.
If you don't do an animation just use the same perspective camera for exporting.
It gets more detail in the front and less far away.
With ortho the detail is the same on the object everywhere.
You have to take into account these kind of things too.
depends on what you want to do and your workflow etc.
I mentioned front projection above...
If you use camera front projection for the method Jordan was using you actually have a small tolerance for moving your camera.
It depends on the move and the render-texture etc. But you could get away from a certain degree of camera change.
So you might not need new renders every time you move your camera. Especially if you plan accordingly.
In all these posts about obj using this or that i forgot to say this to Jordan.
This has been an educating thread. I indeed did an object export from the cropped render camera, imported as it was, and fed the same shaders into the color input of a default shader. As reflective wasn't taken over into that (logical) I added a reflective shader with roughness 0.1, actually all default.
I did the same with the normal micropoly ground.
Render time differs hugely, so it's clear to me that with long rendertimes this is the way to go. Though there is a difference.
So now I wonder if the same would count for transparent objects, like water on plane/sphere. Export sea, import obj and save enormously on render times....
Yeah. Especially with reflection and such there is a huge render time difference.
Difference in detail is normal as you have used most probably a lower resolution export and there is a practicality limit for doing bigger better obj exports etc.
But the difference isn't night and day especially with bigger obj exports.
I was just making a test to show Jordan what i mean.
Below are a standard landscape and one with the landscape as an obj file.
Just a perspective export of 800x. This obj could be 2 times more detailed too if you wanted (with tiled export hugely more detailed).
And the obj rendered even with this just colour look so much faster. With reflection or what not the time difference would be much more.
There is difference in detail but i wouldn't care at all and nobody would know...
I didn't need anything transparency related so haven't tested. Might be something for you to test Ulco.
I suspect if you have a displaced plane, lake...native Terragen object with transparency,
you might get the same speed advantage by exporting and using that instead.
But i don't know if the renderer renders those in the same way like the landscape for sure.
It is most probably as we can use the same displacements.
So it is worth a try especially when i think about your nice wave test images you did-make sometimes.
This is really handy, especially if a lot of ground is covered in veggies, and with a bit of reflective mud underneath. And mainly for big renders of 7k wide or so.
I'll have a go at some wild sea as obj.... curious what will happen.
The only point is that if you render an obj from ground and you import, it sits at the same location, but shouldn't 'mix' with the ground. Therefore I lowered normal ground a bit in the object area. And took off all color/displacement.
I did a test with a 3 part vertically crop rendered exported objects.
I expected seams as i didn't edited and just imported the objects directly into Terragen.
Interestingly there weren't any visible seams at all.
Using objects with different cropped parts (to get more detailed objects or whatever)
or relatively exported by distance, camera etc. is easier then i thought as it looks.
None of my issues is about the time, or that it "doesn't" work. All these blank terrains aren't food examples imo. I want to see completed, fully shaded terrains up close
None of my issues is about the time, or that it "doesn't" work. All these blank terrains aren't food examples imo. I want to see completed, fully shaded terrains up close. Final scenes. I can see difference in your large terrain, which make it obvious as an obj (how low fidelity objects look) and not a landscape imo.
Jordan, you can be sometimes weary as those flatearthers who don't accept any facts showed to them.
I could say more here too. But i already stated that the way the render handles micropolygons is of course much more detailed and advanced ( after all that is one of Terragen's strengths) and this kind of obj work does have another purpose and the difference (if you especially don't have seen the original landscape) is negligible.
You wouldn't know for example that Ulco made that last test with transparency with an object bla bla bla...
It is like you want an image like a macro photo shot.
How is that not close enough?
Mine example and-or Ulco's....more closer wouldn't matter at all but you don't understand that as it looks from you objections.
Is there a special FOV, distance, etc. you accept as...acceptable?
I have really a hard time to understand what you want (Texturing i understand of course).
I picked that scene especially for you according your objections.
Anyway... everybody can work the way they want...
Quote from: WAS on March 30, 2021, 12:58:17 PM... I can see difference in your large terrain, which make it obvious as an obj (how low fidelity objects look) and not a landscape imo.
Which one is obj?
And no you wouldn't have known if i didn't say that at all. If it was fully textured and with atmo.
When you see them side by side maybe. But not by itself.
What you say is something like saying that all the other 3D program who are using polygons do look fake.
I think 2 is the obj.
And again, these are distant terrains, nothing following the scenarios I am talking about.
Quote from: WAS on March 30, 2021, 02:17:51 PMI think 2 is the obj.
And again, these are distant terrains, nothing following the scenarios I am talking about.
Now is the time you should change your thoughts.
No....
1 is the object.
IF 1 is the object, that's even worse, as so much of the terrain detail was changed from the source. Img 2 has a lot of connected details that are severed in image 1.
PS, wanted to try doing a rough ocean, see if it renders fast with brooding lighting, but TG doesn't export planes it looks like. At least not the lake obj. Going to try a plane. If not, planet should work fine blank.
I also gotta say, this looks like a great idea, at the cost of quality.
But I do notice your reflection tests seem to be rendering longer than my PT projection reflection tests. Additionally, if you were to do it in photoshop, it would be perfect, and the PT would render faster then even OBJ reflections.
Your crop tests take about as long as the SR render, and aren't even the full scene. I can do the full scene in about the same time to export reflections, and the PT renders in about half of the time for an object crop for full scene! Then you can composite in reflections in PS and have a highly detailed scene. In my opinion, will still be faster than an OBJ.
Quote from: WAS on March 30, 2021, 02:47:02 PMIF 1 is the object, that's even worse, as so much of the terrain detail was changed from the source. Img 2 has a lot of connected details that are severed in image 1.
I named them especially like 1 and 2 because i knew you could make still an objection. But hoped you won't...
Why wouldn't I? You admitted there is a difference on numerous occasions, it's obvious to me, and if I were doing a scene, such a difference would bother me. If it doesn't bother you, that's fine. Don't argue it continuously. x.x You keep arguing my opinion, and excusing other suggestions, it's a little annoying. I've tested objects plenty now. Have you even tried a projection or composite?
Quote from: WAS on March 30, 2021, 02:53:31 PMI also gotta say, this looks like a great idea, at the cost of quality.
But I do notice your reflection tests seem to be rendering longer than my PT projection reflection tests. Additionally, if you were to do it in photoshop, it would be perfect, and the PT would render faster then even OBJ reflections.
Your crop tests take about as long as the SR render, and aren't even the full scene. I can do the full scene in about the same time to export reflections, and the PT renders in about half of the time for an object crop for full scene! Then you can composite in reflections in PS and have a highly detailed scene. In my opinion, will still be faster than an OBJ.
Could be...i don't know how you use them fully.
Note on planes: A "plane" works to export, but is above 2gb for my ocean test so I can't load it. THe lake doesn't export.
It would be cool if in the future you could have multiple objects in a scene, like planes for water, and they export as object parts. So you could apply materials separately.
Wait, Kadri, you can load files over 2gb? So this is a new issue? You mentioned TG was able to load numerous huge objects?
Quote from: WAS on March 30, 2021, 03:05:48 PMWait, Kadri, you can load files over 2gb? So this is a new issue? You mentioned TG was able to load numerous huge objects?
I am a little confused about that now. I will test my old and new free version and post the results here.
I tested with 3 different size of objects.
Free version v4.5.56:
7.3 Gb No!
3.9 Gb No!
1.9 GB Yes!
Old full version v4.1.25:
7.3 Gb No!
3.9 Gb Yes!
1.9 GB Yes!
The new free version can only load objects around 2 Gb.
While the old full version can load objects around of 4 Gb (probably as i haven't tested with 5-6 Gb objects).
I looked at the version (free-full) comparison page and couldn't find a limit related to the difference.
As CPU and Ram is getting faster and bigger would be good to have higher limits.
My confusion was a little because of that too. In the past a 500-900 Mb obj file was big to me.
Now i use 2-3 GB files easily and more then one of them in a scene.
I get the strange feeling that even if I uncheck the previously used microexporter, a render also adjusts the object. Hmmm. I had made an obj of just the sea, imported and attached a new water shader without displacement, also enabled my sea bottom fake stones again, rendered fine. But when I looked at the obj it had changed in size and comprised of just the latest crop, and also had the fake stones of seabottom.
I did use a normal render, not render to disk.
Btw, I couldn't load a 2.4 gig obj, so I decreased mpd to 0.25, kept size of total render at 1800px wide. Then the first obj was 250MB (before it got mysteriously adjusted).
Ulco i don't know if this is your problem.
But even a normal render (without rendering to disc) is exporting the obj.
I had made the same mistake before too.
You have to unplug the micro exporter to not to overwrite the obj file accidentally.
But just unchecking should work logically. If not that is something that should change in Terragen.
Ulco i made a test and unchecking the micro exporter worked as it should be. No new object was exported.
But this was in v4.1.25. I can't test the newer free version as it doesn't have microexporting.
Could be a new bug or you accidentally made a render (as it doesn't need a render to disc) while it was still checked maybe.
Quote from: Dune on March 31, 2021, 07:05:09 AM...
Btw, I couldn't load a 2.4 gig obj, so I decreased mpd to 0.25, kept size of total render at 1800px wide. Then the first obj was 250MB (before it got mysteriously adjusted).
Depending on software the limit of 32 bit is between 2 GB to 4 Gb so far i know.
The interesting thing is that the old version can go up to 4 GB while the newer one only to 2 GB as it looks in this case.
I may do another test with the micro-exporter checked/unchecked. Perhaps it's a bug. Can't really remember what I did, so have to doublecheck.
Yes, the 2GB limit is probably a bug.
In the menatime I learned that also for a water object it works as expected (making object from sphere, lake doesn't work, like WAS observed too). Here's 4 tests. Guess what's what, and I'll reveal later ;)
There's choice between SR (0.5mpd and AA4); object based or MP based, and PT (mpd 0.5 AA6); object based and MP based.
Quote from: Dune on March 31, 2021, 08:58:14 AM...
(making object from sphere, lake doesn't work, like WAS observed too).
...
No. They work too. But you have to change to "Force displacement" in every object node.
Nice tests. There are differences but all of them usable.
Render time differences by the way?
As i haven't used obj files for transparency before i don't know the characteristics of those renders.
I made just a test to see it working. It renders very fast.
From what i see "tgout-009 - kopie.jpg" and "tgout-006 - kopie.jpg" looks like object renders.
But i wouldn't care if i was wrong or not and still use any of them...or better said which one renders faster.
Yes, right, 6 and 9 are object renders, SR and PT. But indeed all usable, especially for animations (though you'd have to make a lot of objects and import for every frame). But also for stills I'd be happy to use either.
Time differs enormously, from 8min (SR/object) to 1hr16min (PT/micropoly). I'll post the originals now.
Btw. unchecking micro exporter didn't change the object after all.
But a strange thing happened just now. When doing another render this (first) came out.
Water should be no issue to use as it's just volume on depth and reflection. I couldn't test my rough ocean though, I even tried getting a smaller 2000x2000 area and it was just over 2gb and wouldn't load.
I wonder if that strange look is normals not being recomputed? I know TG normals look like absolute garbage in poseray/blender. Like objects just look broken. Because PT I think samples normals for it's subsurface scattering.
So learned some new things tonight.
When you use perspective camera, and have round objects, like a sphere or large round displacement, the back sides don't seem to render to object.
However, there is no issue with the normal/texture coordinates. They're as tight as the geometry is.
But when you use an orthographic camera to export a file from above, or side, you will be able to capture all geometry in 360 degrees of the "round" objects, but the texture coordinates/UV will be huge (producing a detial-less terrain with no shading in Poseray or blender). So with perspective, for some reason a compute terrain with small patch size fixes this, and is needed.
Scratch the other side of geometry issue. Seems actually though, that the distance is doubled. Where the camera was at -5, and the rock at 0,0,0, and distance at 10, it was only getting half the rock at 0,0,0. So I set distance to 20 and it it got all the rock. Strange.
But here is an example of the texture issue where things would be blurry without the compute or I guess texture coordinates.
With my tests there isn't such a drastic difference between ortho and-or compute normal.
The difference is only as expected the way the polygons are handled.
Interesting. Maybe something in your scene or Terragen version is different?
I didn't use any compute, mmm. It needs some clarification, so I'll test again today. I also remember accidently attaching the water shaders, used to make the sea, to the imported object, misinterpreting the top input for shader input, rather than mesh deforming (I was too fast). So I saw this short dialogue, mesh deformed (or something) and normals recalculated.
I wouldn't know what it deformed as it should already be the shape it was, but something may have 'broken' then, perhaps the normals.
Btw. I will test your projection method later, Jordan. Seems like a viable option too.
Hmm...Jordan, i think you export with normals and-or textures checked.
Recalculating normals in Poseray does fix this.
Quote from: Kadri on April 01, 2021, 02:18:47 AMWith my tests there isn't such a drastic difference between ortho and-or compute normal.
The difference is only as expected the way the polygons are handled.
Interesting. Maybe something in your scene or Terragen version is different?
As ive noted Kadri yours terrains are mostly huge and not just a little over a meter showing up close detail. This is just how they load in poseray and if you apply any textures like rock textures it will be painfully obviously and blurry. This same thing effects geometry and masks in TG..smaller patch size and smaller geometric scales are possible (also a lot more tearing), and masks can be more complex effecting disp in like breakup of fuzzy zones. Also effects the size of intersections for depressions and rises.
Normals are unchecked.
Quote from: WAS on April 01, 2021, 02:35:04 AMQuote from: Kadri on April 01, 2021, 02:18:47 AMWith my tests there isn't such a drastic difference between ortho and-or compute normal.
The difference is only as expected the way the polygons are handled.
Interesting. Maybe something in your scene or Terragen version is different?
As ive noted Kadri yours terrains are mostly huge and not just a little over a meter showing up close detail. This is just how they load in poseray and if you apply any textures like rock textures it will be painfully obviously and blurry. This same thing effects geometry and masks in TG..smaller patch size and smaller geometric scales are possible (also a lot more tearing), and masks can be more complex effecting disp in like breakup of fuzzy zones. Also effects the size of intersections for depressions and rises.
Normals are unchecked.
Still have you recalculated normals in Poseray whatever the reason is? It should go away.
It does, but poseray only calculates it all as smooth or flat so its a different look for applied textures/pfs then calculated from geometry scales. Also if its a large obj that crashes poseray or blender its a little hard xD
If its a low MPD obj though recalculating really helps cause sometimes rogue polys seem to loose all definition. Like TG just crapped out calculating normal/texture coordinates.
I already said that texturing after importing is better. That you could get the same textures by front projection etc.
We need something like UV texturing export with Terragen. But until then you have to use what you can.
Close up of 1 meter? Lets say it is problematic...it can be, but it is more after 1 cm or so i think and that can happen to Terragens own detail even. I didn't need that so haven't tested but maybe using higher displacement tolerance could help.
And what is holding you up for using a 10 times, 100 times bigger view and using that as a 1 meter detail?
What you say is nearly saying something like that we have to use nanoscale objects to simulate the atom scale world if we need.
If big landscapes are ok as you say so are small ones too if you use the software accordingly.
That is what i am trying to say to you when you always bring up that close up objection.
Lol... No it's really just saying if your POV includes objects close to the camera, you obviously don't want low octave PFs or textures ruining realism, and this doesn't matter if it's perspective or not, that was just about cut-off geometry, which was actually just the near/far clipping of the micro exporter.
It's like playing a video game, and putting it all on low settings and trying to use it's rocks as a foreground object for the background LODs. It'll look like poopoo (I mean so will the LODs but the rock will be so broken up with blurry textures and visible uv clipping with normals)
Also yeah better micro exporter will be awesome. Matt said better exporting and texturing support was on the roadmap. i think for this year, not sure.
Jordan you are stubborn...not because of only your last post. I have here and in Facebook said more then 3-4 times that to see what problems you have you should share a scene we can work together. But you don't do that and are still continuously nitpicking. Not saying that you are wrong...maybe you are right. But i haven't seen something from you that i could test so much i asked for this. Until you do this i don't think this is going anywhere.
Uploading a nearly 2gb scene is not a simple task using a phone as your internet provider. It takes a long times, and routinely fails to start over. And I've demonstrated this issue above with files loaded straight from TG, you can see this yourself. Using tests hundreds of meters away isn't even trying ot look at what I'm talking about. And then smoothing the whole thing recalculating normals doesn't help the source issue either.
And if we want to go there, here we are on what day, and have you tried simply rendering out a scene in SR with layer elements and compositing it them to a PT render with PT shadows, since the reflections don't really differ too much and take hours longer? I didn't think so... Especeially when from tests above... of CROPS... they take over half the time of a full PT render without reflections. So with exporting OBJs and then a full PT render you could just do a SR layer elements and have a high quality TG scene with no geometry compromises, rendered fast, with a simple two layer comp.
Quote from: WAS on April 01, 2021, 03:54:41 AMUploading a nearly 2gb scene is not a simple task using a phone as your internet provider. It takes a long times, and routinely fails to start over. And I've demonstrated this issue above with files loaded straight from TG, you can see this yourself. Using tests hundreds of meters away isn't even trying ot look at what I'm talking about. And then smoothing the whole thing recalculating normals doesn't help the source issue either.
And if we want to go there, here we are on what day, and have you tried simply rendering out a scene in SR with layer elements and compositing it them to a PT render with PT shadows, since the reflections don't really differ too much and take hours longer? I didn't think so... Especeially when from tests above... of CROPS... they take over half the time of a full PT render without reflections. So with exporting OBJs and then a full PT render you could just do a SR layer elements and have a high quality TG scene with no geometry compromises, rendered fast, with a simple two layer comp.
I don't expect an object. Only scene to see if our exports, renders are different and why etc.
If you said that i would said this. But you haven't even answered that...until now.
Regarding your method why i haven't tested is easy. Because it will work...most probably as i don't know how you use it.
I asked for an example about your method too to see it better remember? I only stated the cons and pros of these methods.
Your method (don't know exactly how you use it but in general elements-layer comping basically) is used since so many years already.
It works of course. You think that i am against it. No! Those kind of ways are used everywhere in the movie industry for example.
We are only talking about different ways and different workflows. Why should i test something i already know that works and is flexible etc.
You can easily change colours etc. without rerendering (everything except moving the camera). I use it myself too in my videos in this and that way.
Not like some pro compers but enough to make my day easier (this paragraph is fully about your method just to be clear).
I only stated the obvious things like that you have to render the elements ones again if you move your camera.
And then added even that i forgot that with front projection you actually have a little more room for camera moves....
Anyway...See you later.
Yeah, re-rendering would be a chore but at that point you should be well through sampling the scene in SR and be decided.
I thought i have given you a few micro exporter scenes? Even before in the past with the rocks when I first had a go. You suspected I was "doing something wrong" then too but i just follow whats stated to do here on the forums by others, and it all seems consistent. You are actually the only one ive seen use perspective and long cone slices of terrain like a projection.
But like I said its a fine method but compute terrain does come in play if you are working at close scales. You can plainly see that in smooth shading and you can test that with any taw export close up on fine detail. I have micro exporters uploaded here, i think the rock exporter too which I used above. I can upload another tomorrow when I get a chance but its literally same file I loaded up and applied a tough repeating texture and PF too.
Quote from: WAS on April 01, 2021, 04:46:09 AM...You are actually the only one ive seen use perspective and long cone slices of terrain like a projection.
...
It is the lazy-easy way. Ortho needs actually tilled obj's to get the same detail (mostly) near the camera. So more work.
And it works well. I've made a new thread, btw, with my results.
Quote from: Kadri on April 01, 2021, 04:54:26 AMQuote from: WAS on April 01, 2021, 04:46:09 AM...You are actually the only one ive seen use perspective and long cone slices of terrain like a projection.
...
It is the lazy-easy way. Ortho needs actually tilled obj's to get the same detail (mostly) near the camera. So more work.
With ortho its the camera height you gotta be aware of. If your disp is only lets say 1m max high, your camera should be like 5-10m on Y and use ortho width/height to cover more area. As if the camera is too far, adaptive micropolygons get simplified.