In article <3C434A75.3455BD71@gmx.de> , Christoph Hormann 
<chr### [at] gmxde>  wrote:

> height fields already work like meshes, i doubt there would be much sense
> for isosurfaces since they don't use much memory.

If you copy an isosurface, the function will be shared.

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

Christopher James Huff wrote:

> Oops, looks like I forgot to include this link:
> http://www.povray.org/3.5-status.html
> "Third, our most recent musings about POV-Ray 4 lean towards a major
> reworking of the POV Scene Description Language. This means that POV 4
> may not be fully backwards compatible with old scenes. If that is the
> case, we will plan to provide an official conversion utility that will
> convert old scenes into the new syntax, or provide some other means of
> importing old scenes."

Exactly. :) Thanks for looking it up.
 
> > Can I make a macro that would calculate a macro that I would pass it in
> > a parameter?
> Not currently. But this has little to do with anything being
> "precalculated", POV just assumes you want the result of a macro call
> instead of the macro identifier, similar problems exist with splines and
> functions. It should be possible to implement with a little parser work.

Well, as people have pointed out, there are some workarounds for it...
but that's precisely what I offered to avoid: workarounds and kludges.
:)
 
> > I would say that scalar is merely a 1-dimensional vector.
> Well, not in the mathematical sense, but probably so practically. Are
> you suggesting some way of specifying the number of components of a
> vector?

That's one possibility. A vector could be a class the instances of which
know their component number, or there are other ways.

Post a reply to this message

> Rick [Kitty5] <ric### [at] kitty5com> wrote:
> : I think a sphere was provided as an example, replace sphere above with 20mb
> : mesh and it suddenly doesn't sound such a bad idea, however impractical it
> : may be
>   Bad example, as povray already does it with meshes.

Okay, replace it with Tree include file which builds a tree out of a few
thousand of POV primitives. Render 10000 copies of that without
referencing of some sort.

Post a reply to this message

> > Can I make a macro that would calculate a macro that I would pass it in
> > a parameter?
> sure. you only need #include, #macro, #fopen and #write directives. So it should
> work when those directives started in POV (3.0 ? 2.0 ?).

... and that is exactly the reason why I started all this - of course
you can do anything at all if you're inventive and have commitment. But
wouldn't it be better if invention and commitment went into creative
work, rather than designing workarounds?

Post a reply to this message

> > Well... What "it"? Implementing these principles in software design? It
> > can be done, if my current pet project, the Quill, is any indication.
> Good, then show us how by making your own patch when 3.5 comes out and you
> can get your hands on the source-code, OK?

Are you sure it even could be done as a patch? Implementing these
features is possible... implementing them as "patch" would be quite
difficult. :)
 
> > It seems that this is the most frequent misunderstanding so far:
> > thinking that I was complaining on features.
 
> If everybody understood what you wrote as such, then it's your own fault for
> badly wording things. For example, this "we" can be taken as being quite
> haughty on your part, and might be seen as implying "Behold, I am the wise
> one, do what I say, because it is better than your meager toilings of the
> past". Or something to that effect. :)

I have little control over what others "might see" - it's their own
choice. What I wrote, I wrote. If it's dismissed only because someone
thought it was "haughty" - okay.

I can only repeat that "I am the wise one" bullshit was not in my
intentions.
 
> > Wouldn't a lubricated machine
> > run better than dry gears?
> Not if the dry gears were coated with teflon or something. ;)

It's like supplying an automobile engine with all the electronic
ignition and extra valves and such - but you still are stuch with the
same old and awkward piston-and-crankshaft architecture, if you allow me
a metaphor...

Post a reply to this message

On Tue, 15 Jan 2002 09:27:41 +0200, Eugene Arenhaus <eug### [at] avalon-netcoil>
wrote:
> Are you sure it even could be done as a patch?

AFAIK parsing functions are not connected with rendering functions for objects,
initializing functions for data etc. Have you checked this ?

> Implementing these
> features is possible... implementing them as "patch" would be quite
> difficult. :)

Writing new parser without changing other stuff is
IMO no more difficult than organizing MegaPOV by Nathan and/or
IMO no more difficult than adding shader by Vahour.
Somehow Chris Huff started with new syntax.
 
ABX

Post a reply to this message

> IMO no more difficult than organizing MegaPOV by Nathan and/or

*ahem*

-- 
#local R=<7084844682857967,0787982,826975826580>;#macro L(P)concat(#while(P)chr(
mod(P,100)),#local P=P/100;#end"")#end background{rgb 1}text{ttf L(R.x)L(R.y)0,0
translate<-.8,0,-1>}text{ttf L(R.x)L(R.z)0,0translate<-1.6,-.75,-1>}sphere{z/9e3
4/26/2001finish{reflection 1}}//ron.parker@povray.org My opinions, nobody else's

Post a reply to this message

Ron Parker wrote:

> *ahem*

Would you prefer et. al. ?

-- 
Ken Tyler

Post a reply to this message

On 15 Jan 2002 08:41:26 -0500, Ron Parker <ron### [at] povrayorg> wrote:
> > IMO no more difficult than organizing MegaPOV by Nathan and/or
>
> *ahem*

and/or creating of UVPov, SuperPatch, MultiPatch etc.

(enough?)

ABX

Post a reply to this message

In article <3C43D729.26CCEBFB@avalon-net.co.il>,
 Eugene Arenhaus <eug### [at] avalon-netcoil> wrote:

> That's one possibility. A vector could be a class the instances of which
> know their component number, or there are other ways.

In CSDL there are currently these types:
scalar: double-precision floating point number.

3D vector: double-precision FP vector. Only 3D because various math 
functions will rely on 3D points, if you need more you should use arrays 
of scalars.

string: Just a basic string storage type, a String object to manipulate 
them will be provided.

stream: I/O, as with strings, specialized objects using streams will be 
provided.

object: Well, the object type.

function: Functions, with parameters and return values passed by 
reference.

I also plan to have two kinds of arrays: a more compact kind which 
stores one type, and an expanded kind which can store any type.

-- 
 -- 
Christopher James Huff <chr### [at] maccom>

Post a reply to this message