Le 20/06/2010 11:14, SharkD nous fit lire :
> On 6/20/2010 4:54 AM, Thorsten Froehlich wrote:
>>> Explicit #RETURN statement inside macros
>>
>> You are misunderstanding that macros are not functions. There is no such
>> thing as a return from a macro.
> 
> OK, I see now that a return statement wouldn't work in a macro. A macro
> can return an arbitrary block of code that could be completely
> unstructured.
> 

BS: a macro does *NOT* return, it get expanded.
It can be expanded to any thing.
If you think of macro as functions, you are deceiving yourself and
preparing for more problems.

>>> Ability to change the order of editor tabs by dragging them
>>
>> This is Windows only, I suppose.
> 
> Why is that? Are Linux users too primitive to benefit from this feature?
>

Hello.... anybody inside ? There is no Linux front-end.
(But povclipse is a nice module for eclipse & povray)

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

The problem is that you have to take into account the time to generate
the mesh itself (otherwise it would be cheating)... or work like other
renderers: with mesh file (already generated) only.

Mesh is a cheap inaccurate solution when you can have an exact
mathematical shape instead. They have their interest, but are not panacea.

When all you have is a hammer, everything looks like a nail.
That's what happens within other renderer: all they support is a
triangle, so only meshes are available.
(even Nurbs get transformed into collection of triangles)

Post a reply to this message