In article <3a697e3b@news.povray.org>, "Rune" <run### [at] inamecom> 
wrote:

> "Chris Huff" wrote:
> > they would only return a component at a time.
> > (vrotate_x(px, py, pz, rx, ry, rz), vaxis_rotate_y(), etc...
> 
> Ough!

That was my solution for handling vectors in a float-based function...it 
probably wouldn't be impossible to extend functions to handle vectors as 
well.


> But isosurfaces and meshes are completely different things!
> Isosurfaces are fields defined for every point in space. A surface is
> created wherever the field equals a certain value. Meshes are completely
> different. There's no field, there's just a bunch of points in space
> connected by triangles.
> 
> For isosurfaces it makes sense to change the field values by using 
> functions that return floats.
> 
> For meshes it makes sense to directly move the vector points by using
> functions that return vectors.

You have completely missed the point...
This has *nothing* to do with isosurfaces, it's about executing 
user-written code multiple times at a later time, between parse and 
render time or even at render time. With macros, you can't do that, and 
functions are the only things that can do that (well, forget about 
shaders for the moment, since they are specialized for color processing, 
but they may also be a solution), so it makes sense to use them as an 
example and a base for the vector stuff.

Since this specific application only needs to be done at parse time, it 
should be possible to use macros (if you can figure out how, I attempted 
this as part of my particle system patch but never figured it out), but 
speed will suffer, and there are other applications of the same thing 
that would need to be done at render-time.


> But it's two completely different things! It wouldn't make sense to make
> them consistent or to use them together.

Why not? Each component of a vector is a float, allowing the user to use 
float functions in vector functions would be very powerful. And I don't 
see a reason to make another, very different version of the syntax just 
to support vector functions. They are *very* closely related, the only 
difference is that one handles scalars and the other handles vectors.


> > And if you really want to use a macro, you could always read
> > the data from the mesh, do what you want with it using a
> > macro, and create a new mesh with it.
> Err Chris, that's what I'm already doing.

Why do you think I mentioned it? ;-)


> This whole thread origins from my message in 
> povray.binaries.animations with an example of a mesh deformed by a 
> macro. But I was discussing with ABX if a patch could do it as easily 
> and flexibly (to the user) as a macro.
> Seems that it can't...

As flexibly? No...not without a lot of changes and additions. How easy 
it would be would depend on your needs, a macro based solution will be 
easy to modify to suit your needs but far slower.

-- 
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message