|
|
On 6/11/24 14:17, Thorsten wrote:
> It is impossible to predict the complexity with modern CPU, I think.
I agree. Today's hardware optimizations make performance tuning a tough
trick - and make questionable a number of "rules of thumb" about which
algorithms perform best.
>
> The benefit would be that the "texturing" would become a completely
> separate task, and could actually be done (sans reflection and
> refraction) after tracing, which, if nothing else, would lead to a cool
> looking render preview. The other effect would be that at least bounding
> optimisations and mesh intersection testing could be done on a GPU.
>
> Yet another benefit you get from separating the tracing and the
> texturing is that you end up with a sort of frame buffer that contains
> object data. An idea I never pursued to the end 20 or so years ago was
> that this gives rise to the ability to edit a ray-traced scene on the
> fly because you have access to the objects making up an individual pixel
> and can separate objects in and out of the scene as long as the camera
> doesn't move.
Cool ideas. :-) I can see how some parts might work, but far from all of
it.
Our ray tracing and texturing is today tangled in places (adc bailout,
filtering/transparency, media, object modifiers). There is too how to
handle anti-aliasing (AA) / camera focal blur.
Though our 'AA' approach today is expensive(a), it's a strength with
respect to 'true result' that each sample ray considers the scene -
including texturing - alongside all the ray tracing / branching in total.
Bill P.
(a) - With respect to performance, on my 'try it someday' list are
cheaper AA / focal blur modes where the rays beyond some 'sampling
depth/count' would terminate at a much shallower max_trace_level/sample
count(*). Or maybe we gradually reduce the trace depth in opposition to
the AA/blur sampling 'depth'. Results would be less true, but I
'suspect' they'd often look good as a rule. (There is a tradeoff buried
in the idea as the less accurate results due shallower ray trace depth
would sometimes itself trigger additional sampling - and sometimes not
where we would otherwise have shot more rays.)
(*) - Yes! I made trying the idea harder by implementing the forced min
sampling AA in yuqk.
Post a reply to this message
|
|