work-around for slow PT reflection calculation

[Kadri]

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.

[Dune]

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.

[WAS]

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.

[WAS]

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.

[WAS]

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.

[Kadri]

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?

[Dune]

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.

[Kadri]

Hmm...Jordan, i think you export with normals and-or textures checked.
Recalculating normals in Poseray does fix this.

[WAS]

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?

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.

[Kadri]

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?

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.

[WAS]

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.

[Kadri]

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.

[WAS]

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.

[Kadri]

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.

[WAS]

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.