Re: [Visualpython-users] Further adventures with primitives

[Jonathan B. <jbr...@ea...>]

On Wed, 2003-02-19 at 17:48, Press, Shaun wrote:
> I have managed to add Tetrahedron, Pyramid and Frustum to the primitive
> shapes in my copy of Visual Python.
> The terahedron and pyramid a pretty simple to do as they are a specific form
> of the cone shape. 

--snip--

> The frustum was a little more frustrating to get right. In the end I made a
> copy of cylmodel.h and called it frustmodel.h. I then modifed the method
> that returns the vertices of the cylinder to set the top vertices at half
> the radius of the bottom ones. Trying to do this inside the frustum
> projection loop in frustum.cpp caused some bizzare results.
> I had hoped to avoid making almost identical copies of other modules as this
> adds to code bloat, but for the moment this will do.

If they are nearly identical, is it possible to create a conic_base
class, and implement the cone-like shapes as specializations of the base
class?  That would cut down on the redundancy.  It would also be an
excellent modification to the library.

> I haven't added any new attributes to the shapes, instead relying on the
> ones provided. That means that the size of the base of the
> pyramid/tetrahedon uses the radius attribute and is the distance from the
> mid point of the base to the corner vertex. For the frustum the radius at
> the top is fixed to be half the radius of the base.

So you are already inheriting from axialSymettry?  Maybe conic_base can
have a protected member function (or several) that represents the shared
code between the different models.  Then, pyramid, tetrahedron,
cylinder, cone, and frustm would only implement the varient code with
glRender, calling the private functions of the base class for the common
stuff.  Something like a base_verticies function or the like.  Also, if
a minor_radius property is useful to frustm, we can add it as a property
of conic_base.  However, adding extra properties is clumsy right now. 
Moving to Boost will make extensions like this much easier.  You might
want to go ahead and implement it with a temporarily fixed value for
now.

> BTW As I remarked in my first post frustum is not a good name for this
> shape, at least internally, as it causes compile errors due to the clash
> with the frustum methods used to handle the camera in openGl. I've called it
> frustm in the short term but does anyone have a better suggestion?

As part of the move to Boost, I plan to place all of the classes and
free functions within cvisual into namespace cvisual:: (or maybe just
visual::).  Long term, this should prevent clashes with the OpenGL and
other function namespaces.

-Jonathan