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.



>> As for setting/overriding metrics, even an HTML coder can override
>> things like x height using things like font-size-adjust and font-stretch.
>
> Yes, it is called "scale" in POV-Ray ;-)

See:

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.



>> I was talking about sub-topics within extremely long pages. No, the
>> Windows help docs can't help you there as they don't track what topic
>> you're reading at any given moment.
>
> Hmm, I am not sure how a table of contents at the top of such a page (as
> you suggested) would help you keep track of where you are on that page.
> I know that PDF table of content views get updated as you move through
> the document, but I am not aware of any HTML feature (sans JavaScript)
> that could do this interactively.

Sure it would help. All I would have to do is press the Home key to go 
to the top of the page and then click on the sub-heading link. Same as 
if I were visiting Wikipedia or something.



> Please refer to the bug report. What is needed is the version of POV-ray
> you are using, and the error message displayed. The background here is
> (as explained in the comment for that feature request) that the code
> does not have a limit of 20 paths internally, so the problem must be
> coming from some platform specific code that has not been updated. - It
> is correct that there was such a limit in 3.6, but you reported the
> problem against 3.7 beta where it should be exist. That is also my I
> changed the "feature request" to "possible bug".

In this case I went by the docs alone and didn't think to test the 
behavior in the beta first. Sorry.



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



>> Why is that? Are Linux users too primitive to benefit from this feature?
>
> Yes, they are! They have no editor supplied by POV-Ray!

Didn't realize this, sorry.



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



>> 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



>> There are already sind, tand, cosd, tan2d, etc. Why not also tand? Too
>> conspicuous for you?
>
> Well, I see now. You really need to write more than "There already exist
> atan, atan2 and atan2d functions, why not atand?" as a feature request.
> Both "atan" and "atan2" are built in functions. "atand" is not. Now that
> you mentioned the other ones, I had a chance to notice that these
> functions are indeed defined - in "math.inc". That would have been the
> minimum additional necessary information needed to figure out what you
> were up to. Now I know, and indeed have simply added it. So in the next
> beta you should find a
> #declare atand = function (x) {degrees(atan(x))}
> in "math.inc".

Yeah, sorry, I didn't see that it was in "math.inc" either.



-- 
http://isometricland.com

Post a reply to this message