There are a couple of primitives I'm thinking of suggesting for V4.
Since I'd like to do all the legwork for implementing these primitives
(writing the ray intersection tests, automatic bounding calculations,
etc), so that the suggestion will put less work on the POV-Ray team,
excatly what functions are needed to fully support a primitive
under POV-Ray?

Regards,
John

Post a reply to this message

John VanSickle <evi### [at] hotmailcom> wrote:
> There are a couple of primitives I'm thinking of suggesting for V4.
> Since I'd like to do all the legwork for implementing these primitives
> (writing the ray intersection tests, automatic bounding calculations,
> etc), so that the suggestion will put less work on the POV-Ray team,
> excatly what functions are needed to fully support a primitive
> under POV-Ray?

  Would it be possible for you to mention which types of primitives are
you thinking about?

-- 
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  - Warp -

Post a reply to this message

In article <3D4B7962.DF754423@hotmail.com>,
 John VanSickle <evi### [at] hotmailcom> wrote:

> There are a couple of primitives I'm thinking of suggesting for V4.
> Since I'd like to do all the legwork for implementing these primitives
> (writing the ray intersection tests, automatic bounding calculations,
> etc), so that the suggestion will put less work on the POV-Ray team,
> excatly what functions are needed to fully support a primitive
> under POV-Ray?

Well, POV 3.5 uses methods that compute the normal, insideness of a 
point, all intersections with a ray, UV coordinates, copy/destroy the 
shape, invert the shape, and the various transformations (translate, 
rotate, scale, and transform). There are also functions for creation and 
computing bounding boxes, and sometimes others. Make a 3.5 patch and it 
shouldn't be too hard to adapt for 4.0, but it is likely you would have 
to rewrite most of the code, and there could be very different 
requirements.

Going to give any hints as to what you are planning? ;-)

-- 
Christopher James Huff <chr### [at] maccom>
POV-Ray TAG e-mail: chr### [at] tagpovrayorg
TAG web site: http://tag.povray.org/

Post a reply to this message

Warp wrote:
> 
>   Would it be possible for you to mention which types of primitives
> are you thinking about?

Two rather ambitious ones:

First, incorporate quadrilaterals into the mesh object.  This would
make polygon modelling simpler.

Second, a recursive object (ie, a fractal).

Regards,
John

Post a reply to this message

In article <3D4EC82C.C892E71F@hotmail.com>,
 John VanSickle <evi### [at] hotmailcom> wrote:

> First, incorporate quadrilaterals into the mesh object.  This would
> make polygon modelling simpler.

That wouldn't really be a primitive, just an addition to the mesh 
syntax. Probably quite easy, just look at how it parses triangles and 
add code to parse a quad instead, splitting it into two triangles to add 
to the mesh.


> Second, a recursive object (ie, a fractal).

Like an L-system? That would be very interesting...I haven't done 
anything with them. Not sure how useful it would be though.

-- 
Christopher James Huff <chr### [at] maccom>
POV-Ray TAG e-mail: chr### [at] tagpovrayorg
TAG web site: http://tag.povray.org/

Post a reply to this message

"Christopher James Huff" <chr### [at] maccom> wrote in message
news:chr### [at] netplexaussieorg...

> > Second, a recursive object (ie, a fractal).
>
> Like an L-system? That would be very interesting...I haven't done
> anything with them. Not sure how useful it would be though.

Why not just script one?

...Chambers

Post a reply to this message

Christopher James Huff wrote:

> In article <3D4EC82C.C892E71F@hotmail.com>,
>  John VanSickle <evi### [at] hotmailcom> wrote:
> 
> 
>>First, incorporate quadrilaterals into the mesh object.  This would
>>make polygon modelling simpler.
>>
> 
> That wouldn't really be a primitive, just an addition to the mesh 
> syntax. Probably quite easy, just look at how it parses triangles and 
> add code to parse a quad instead, splitting it into two triangles to add 
> to the mesh.
> 
 
Why stop at the quadrilateral, let's have also a plain polygon

(no hole) in the mesh parser (while still storing only triangles).
Then handling the quadrilateral is just a subcase of the generic polygon.

Post a reply to this message

In article <3d4f7bdd@news.povray.org>,
 "Ben Chambers" <bdc### [at] yahoocom> wrote:

> > > Second, a recursive object (ie, a fractal).
> > Like an L-system? That would be very interesting...I haven't done
> > anything with them. Not sure how useful it would be though.
> 
> Why not just script one?

Simple: slow parsing. Since POV 4.0 will probably use a VM for the 
language, that isn't such a big deal for the future.

-- 
Christopher James Huff <chr### [at] maccom>
POV-Ray TAG e-mail: chr### [at] tagpovrayorg
TAG web site: http://tag.povray.org/

Post a reply to this message

Ben Chambers wrote:
> 
> "Christopher James Huff" <chr### [at] maccom> wrote in message
> news:chr### [at] netplexaussieorg...
> 
> > > Second, a recursive object (ie, a fractal).
> >
> > Like an L-system? That would be very interesting...I haven't done
> > anything with them. Not sure how useful it would be though.
> 
> Why not just script one?

To allow memory to be saved (at the expense of rendering speed, but
some people would welcome that).

Regards,
John

Post a reply to this message

Le Forgeron wrote:
> 
> Christopher James Huff wrote:
> 
> > In article <3D4EC82C.C892E71F@hotmail.com>,
> >  John VanSickle <evi### [at] hotmailcom> wrote:
> >
> >>First, incorporate quadrilaterals into the mesh object.  This would
> >>make polygon modelling simpler.
> >>
> >
> > That wouldn't really be a primitive, just an addition to the mesh
> > syntax. Probably quite easy, just look at how it parses triangles
> > and add code to parse a quad instead, splitting it into two
> > triangles to add to the mesh.
> 
> Why stop at the quadrilateral, let's have also a plain polygon
> 
> (no hole) in the mesh parser (while still storing only triangles).
> Then handling the quadrilateral is just a subcase of the generic
> polygon.

I was actually thinking of storing the quads as quads, internally,
on the guess that they can be optimized to the point that they render
faster than the two triangles that would replace each.

Maybe not.

I'm also working on my subdivision surface macros, and have found a
way to extend the Loop surface to support quadrilaterals in addition
to triangles; hence my interest in adding that to the mesh.

Regards,
John

Post a reply to this message