On 9/5/23 18:59, Samuel B. wrote:

> Parsing and render times.

Of course quite a bit longer with dens_object. No getting around there 
being a lot more work getting done. Let's see. A render of just the R - 
no normal{} at all on my old 2 core i3:

   1.50user 0.03system 0:01.26elapsed

and with a dens_object normal 'similar' to that posted prior.

   69.96user 0.11system 0:18.82elapsed

using both times the command line:

   povr dens_object_02.pov +w800 +h600 +a0.05 +am2 +r3 +j3.33


 > This povr fork sounds interesting. Does it allow an object's normal 
to > be completely overridden?

Only a little more so than the usual POV-Ray at this point. As we 
increase the normal{} block bump_size beyond 0.5 we already start to, 
for example, invert normals. The larger that bump_size the more the 
perturbation influence becomes the total perturbed normal. This 'take 
over' usually at the cost of some distortion to the intended result.

In povr, I've played some with chained normal perturbations which 
replace the raw normal with more perturbations due the chaining.

I have not, though, thought about selectively replacing raw normals 
completely with some other entirely. This would be hard to do in general 
(with a switch say) but say maybe if using other shapes to paint in 
replacements always from the outside / inside we could make the 
replacement orderly... I'll think about it.

 > I've been thinking about making a fork of my own.

It's work - and sometimes frustrating for sure - but you can also try 
what you want. To some degree you get to use what you want from other 
forks too.

> Have you tried it with specular highlights or reflection?

I've not played with finishes yet.

I did spec a little time with the accuracy(a) setting which has some 
effect. The 0.02 accuracy default shown in the earlier posting is as 
much blunting corners (except for the opposing seams - which stick 
around) as rounding them when looked at on closer renders. A smaller 
accuracy setting looks more rounded,  but pretty quickly also better 
shows additional discontinuities in the normals.

(a) - I have some long standing concerns with this keyword's 
implementation with respect to bias and an internal 'magic factor' there 
in the code, but not described. I dislike 'magic' code because it almost 
always disconnects users from any intuitive feel for what setting would 
be best. Anyhow, I might use dens_object based normals to play with that 
accuracy code some... We'll see.

Bill P.

Post a reply to this message