work-around for slow PT reflection calculation

Started by Dune, March 23, 2021, 12:41:48 PM

Previous topic - Next topic

Kadri

#135
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.

WAS

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.

Kadri

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.

Dune

And it works well. I've made a new thread, btw, with my results.

WAS

Quote from: Kadri on April 01, 2021, 04:54:26 AM
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.

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.