On 20.06.10 12:18, SharkD wrote:
> On 6/20/2010 5:44 AM, Thorsten Froehlich wrote:
>>> "Clever use" means tedious work that gets repeated by users over and
>>> over and over again. If it's so good then the devs can be "clever"
>>> enough to add the feature.
>>
>> Well, I would be all for someone contributing a set of macros for the
>> POV-Ray 3.7 include file collection to avoid any repetition.
>
> Sure. And until then there's no reason for its removal from bugtracker.

Its not removed. It is closed. All closed bugs are still visible.

> http://webdesignernotebook.com/css/the-little-known-font-size-adjust-css3-property/
>
> Scaling based on x height is not as easy as scaling based on font
> height. It requires knowledge of said font metrics.

The link is about aspect ratios when substituting fonts. In effect what is 
describes is just a clever algorithm to scale characters in one font such 
that they take about as much space as another font. You can do the same with 
min_extent and max_extent in POV-Ray, and then scale another font accordingly.

>> No, this syntax will not work. I actually just noticed that i added the
>> explanation to report 127 (rather than 128). Among other things, you can
>> do things like this:
>>
>> #declare foo = array[2];
>> #declare foo[0] = array[2];
>> #declare foo[1] = array[7];
>> #declare foo[0][0] = 2;
>> #declare foo[1][6] = sphere{1,1}
>
> Very, very ugly. The char count of the above code jumped from 45 chars
> to 135 chars. And, there's now an introduced chance of an undetected
> error occurring if one were to type/change the indices incorrectly that
> povray would never report.

It is just an example I had at hand.

>>>>> Native support for mesh-based surface approximations
>>>>
>>>> You can already do this with a macro. Native support would have no
>>>> benefit - the probable assumption that a high quality mesh would be
>>>> faster to generate and then render compared to a native object (i.e. an
>>>> isosurface) is incorrect.
>
> I originally meant this to be for the simple native CSG objects only,
> not for complex CSG combinations. I.e. spheres, cones and cylinders, as
> well as isosurfaces and parametric objects. Not for intersections or
> other CSG combinations. Basically equivalent to what Moray is capable of
> doing.

Someone suggested meshes instead of CSG? That is not very sensible at all. 
To speed up CSG obejcts, you should use manual bounding.

>>> Pray tell me then why people have taken the time to write these complex
>>> macros if there is no benefit? Just this week I've been told at least a
>>> half a dozen times that my scenes would render faster if I replaced my
>>> objects with meshes.
>>
>> By whom, and where?
>
> "Shape help" in p.g
> "Chris Colefax's Object Bender -- SLOW!!!" in p.a-u
> "Spinner" space colony (2)" in p.b.i

The object binder macro (I saw that thread, no time to read the others) is a 
rather complex solution to modifying objects in ways that are not really 
possible without, well, changing their mathematical representation. A mesh 
is a workaround for such an object to be modified within POV in a way that 
you would normally modify it in a 3D modeler. Those models usually work with 
meshes and hence make the modifications possible because the triangle meshes 
have certain properties that make non-linear transformation mathematically 
"easy". So the suggestion in that thread more or less is to use a modeler. 
Using the object bender macros on a mesh in POV-Ray would not make it any 
faster.

     Thorsten

Post a reply to this message