How about cylinders/cubes/cones that you can define the endpoints of,
instead of having to rotate & scale them?
I can see a plugin that has just these normal primitives, but with a numeric
entry :

Cube - enter x1,y1,z1 and x2,y2,z2
Cylinder - enter x1,y1,z1 ,  x2,y2,z2  , radius
Cone - enter x1,y1,z1 ,  x2,y2,z2  , radius1, radius2


It would make life MUCH simpler, as well as make cleaner code than taking a
unit cylinder and scaling/rotating/translating.

Twyst
--
------------------------------------------------------------
povray.doc -- An engaging tale about a spanish guy named Manual.
------------------------------------------------------------

Post a reply to this message

Twyst wrote:
> 
> How about cylinders/cubes/cones that you can define the endpoints of,
> instead of having to rotate & scale them?
> I can see a plugin that has just these normal primitives, but with a numeric
> entry :
> 
> Cube - enter x1,y1,z1 and x2,y2,z2
> Cylinder - enter x1,y1,z1 ,  x2,y2,z2  , radius
> Cone - enter x1,y1,z1 ,  x2,y2,z2  , radius1, radius2
> 
> It would make life MUCH simpler, as well as make cleaner code than taking a
> unit cylinder and scaling/rotating/translating.
> 
> Twyst
> --
> ------------------------------------------------------------
> povray.doc -- An engaging tale about a spanish guy named Manual.
> ------------------------------------------------------------

Are you trying to be funny or am I missing something here ?

A quick example of defining end points on a cylinder would be:

for x
cylinder{x*-1,x*1,1>}

for y
cylinder{y*-1,y*1,1>}

for z
cylinder{z*-1,z*1,1>}

for cones you can do the same thing

for x
cone{x*-1, 1, x*1, 0>}

for y
cone{y*-1, 1, y*1, 0>}

for z
cone{z*-1, 1, z*1, 0>}

and for cubes it takes a little more work but you can
do about the same as above

box{-.5,.5}
 a unit cube

box{0,1}
a unit cube that extends from lower left corner at
xyz = 0 to xyz +1

If you use all six direction vectors in the cylinder and
cone primitives you can scale and rotate them any direction
you like without have to further rotate and scale them with
extra statements.

Have I missed something ?

-- 
Ken Tyler

mailto://tylereng@pacbell.net

Post a reply to this message

Ken wrote:

> Twyst wrote:
> >
> > How about cylinders/cubes/cones that you can define the endpoints of,
> > instead of having to rotate & scale them?
> > I can see a plugin that has just these normal primitives, but with a numeric
> > entry :
> >
> > Cube - enter x1,y1,z1 and x2,y2,z2
> > Cylinder - enter x1,y1,z1 ,  x2,y2,z2  , radius
> > Cone - enter x1,y1,z1 ,  x2,y2,z2  , radius1, radius2
> >
> > It would make life MUCH simpler, as well as make cleaner code than taking a
> > unit cylinder and scaling/rotating/translating.
> >
> > Twyst
> > --
> > ------------------------------------------------------------
> > povray.doc -- An engaging tale about a spanish guy named Manual.
> > ------------------------------------------------------------
>
> Are you trying to be funny or am I missing something here ?

<snip>

I think his point is for odd angles, and the such.

If I want to connect the points 0,0,1 and 0,1,0 with a cyllinder or cone, it would
lie on an angle. BUT, it would also have to have a length of [root 2].

For other points to be connected, other lengths are needed.. and since Moray is a
visual modeller, it would be nice to be able to do this without using a
calculator.

I've wanted this myself...

Plus, for a cylinder , cone, or cube, the scaling is applied after the texture,
resulting in an often distorted texture, unless you put the object into a group,
and apply the texture to the group. For multiple items this is fine, but if you
want to apply a texture to just one object, it's a bit irritating.

Simon
http://home.istar.ca/~sdevet

Post a reply to this message

Simon de Vet wrote:
> 
> Ken wrote:
> 
> > Twyst wrote:
> > >
> > > How about cylinders/cubes/cones that you can define the endpoints of,
> > > instead of having to rotate & scale them?
> > > I can see a plugin that has just these normal primitives, but with a numeric
> > > entry :
> > >
> > > Cube - enter x1,y1,z1 and x2,y2,z2
> > > Cylinder - enter x1,y1,z1 ,  x2,y2,z2  , radius
> > > Cone - enter x1,y1,z1 ,  x2,y2,z2  , radius1, radius2
> > >
> > > It would make life MUCH simpler, as well as make cleaner code than taking a
> > > unit cylinder and scaling/rotating/translating.
> > >
> > > Twyst
> > > --
> > > ------------------------------------------------------------
> > > povray.doc -- An engaging tale about a spanish guy named Manual.
> > > ------------------------------------------------------------
> >
> > Are you trying to be funny or am I missing something here ?
> 
> <snip>
> 
> I think his point is for odd angles, and the such.
> 
> If I want to connect the points 0,0,1 and 0,1,0 with a cyllinder or cone, it would
> lie on an angle. BUT, it would also have to have a length of [root 2].
> 
> For other points to be connected, other lengths are needed.. and since Moray is a
> visual modeller, it would be nice to be able to do this without using a
> calculator.
> 
> I've wanted this myself...
> 
> Plus, for a cylinder , cone, or cube, the scaling is applied after the texture,
> resulting in an often distorted texture, unless you put the object into a group,
> and apply the texture to the group. For multiple items this is fine, but if you
> want to apply a texture to just one object, it's a bit irritating.
> 
> Simon
> http://home.istar.ca/~sdevet

Actually I did reply in haste. I thought this was the povray.windows
group. I understand the difficulties inherent in such a feature when
talking about modeling programs. I couln't believe Twyst didn't know
how easy it was to define end points in pov. My mistake and apologize
for the quick fire response. It does build good a argument for hand
coding though :)

-- 
Ken Tyler

mailto://tylereng@pacbell.net

Post a reply to this message

Ken wrote in message <36C1C438.71E40BA0@pacbell.net>...
>Twyst wrote:
>>
>> How about cylinders/cubes/cones that you can define the endpoints of,
>> instead of having to rotate & scale them?
>> I can see a plugin that has just these normal primitives, but with a
numeric
>> entry :
>>
>> Cube - enter x1,y1,z1 and x2,y2,z2
>> Cylinder - enter x1,y1,z1 ,  x2,y2,z2  , radius
>> Cone - enter x1,y1,z1 ,  x2,y2,z2  , radius1, radius2
>>
>> It would make life MUCH simpler, as well as make cleaner code than taking
a
>> unit cylinder and scaling/rotating/translating.
>>
>> Twyst
>> --
>> ------------------------------------------------------------
>> povray.doc -- An engaging tale about a spanish guy named Manual.
>> ------------------------------------------------------------
>


>Are you trying to be funny or am I missing something here ?

>Have I missed something ?


Yup. This is for MORAY. there is NO current way to define where your
endpoints are WITHOUT having to do a LOT of scaling/rotating.

Notice how you have to build a cylinder currently.
you click cylinder.
It places a 1x1x1 cylinder at the origin
you scale it to the right dimensions
You rotate and translate it until you get it right.
(Case in point: YOU do a cylinder with points <2.3,1.2,3> <.15,8.2,2.5>
without spending 5 minutes doing s/r/t to make it fit.)
Repeat for each cylinder in a scene.
Output code:

cylinder { // Cylndr001
  <0,0,1>, <0,0,0>, 1
  material {
    PDB_Tex_C
  }
  scale <0.7, 1.0, 6.9>
  rotate 35.0*y
  translate  <3.6, 0.0, 1.3>
}


Now, the plugin:

You click Cylinder[2 point]
It puts a 1x1x1 cylinder at the origin.
You enter the first point. <2.3,1.2,3>
It places endpoint 1 there.
You enter the second point. <.15,8.2,2.5>
It places endpoint 2 there.
You enter the radius.
It changes the radius.
Done. MUCH faster to do.

Output code:
cylinder { // Cylndr001
  <2.3,1.2,3> , <.15,8.2,2.5> , 1
  material {
    PDB_Tex_C
  }
}


MUCH cleaner.

>--
>Ken Tyler
>
>mailto://tylereng@pacbell.net


Twyst
--
------------------------------------------------------------
povray.doc -- An engaging tale about a spanish guy named Manual.
------------------------------------------------------------

Post a reply to this message

>Actually I did reply in haste. I thought this was the povray.windows
>group. I understand the difficulties inherent in such a feature when
>talking about modeling programs. I couln't believe Twyst didn't know
>how easy it was to define end points in pov. My mistake and apologize
>for the quick fire response. It does build good a argument for hand
>coding though :)
>
>--
>Ken Tyler
>
>mailto://tylereng@pacbell.net

Actually, I do both. I do my major scene layout in Moray, and tweak it in my
SuperPatch enabled Pov-Ray.

I also code quick custom programs to generate objects for Moray -- my latest
trick is to hack LParser and a) fix the DXF output, and b) change the BLB
format to CTD format (which I convert using another program.) (massive
kludge, doesn't work all that well. =( I need to sit down and write a
LParser for Moray.. .  Eventually. AFTER I get everything else done.)

Twyst
--
------------------------------------------------------------
povray.doc -- An engaging tale about a spanish guy named Manual.
------------------------------------------------------------

Post a reply to this message

Twyst schrieb in Nachricht <36c1c038.0@news.povray.org>...
>How about cylinders/cubes/cones that you can define the endpoints of,
>instead of having to rotate & scale them?
>I can see a plugin that has just these normal primitives, but with a
numeric
>entry :
>
>Cube - enter x1,y1,z1 and x2,y2,z2
>Cylinder - enter x1,y1,z1 ,  x2,y2,z2  , radius
>Cone - enter x1,y1,z1 ,  x2,y2,z2  , radius1, radius2
>
>
>It would make life MUCH simpler, as well as make cleaner code than taking a
>unit cylinder and scaling/rotating/translating.


YES! It would really make life simpler. Especially, if you want to use the
cylinders to define blobs. If you enlarge a unit cylinder (esp. if you
elongate it), the rounded edges of the blob cylinder will we elongated too.
This is not the desired effect.

But they would have to be real cylinders, not converted to
translated/rotated/scaled cylinders after all (but I don't know if a plugin
can do this).

I've had a look at the C++ code for Moray plugins, but I'm lost with the
VC/MFC objects. If I'd only have the definition of the MFC class CObject,
I'd be able to translate the MFC C++ headers to Delphi32 (yes, this is
possible) and create any kind of plugin desired.

--
Rudy Velthuis

Post a reply to this message

> I've had a look at the C++ code for Moray plugins, but I'm lost with the
> VC/MFC objects. If I'd only have the definition of the MFC class CObject,
> I'd be able to translate the MFC C++ headers to Delphi32 (yes, this is
> possible) and create any kind of plugin desired.
You don't need to use MFC stuff to make a plugin. The Plugin SDK has a
pure C Win32 API version that uses no MFC stuff.

- Lutz
  email : lut### [at] stmuccom
  Web   : http://www.stmuc.com/moray

Post a reply to this message

Lutz Kretzschmar schrieb in Nachricht <36c### [at] newsstmuccom>...
>> I've had a look at the C++ code for Moray plugins, but I'm lost with the
>> VC/MFC objects. If I'd only have the definition of the MFC class CObject,
>> I'd be able to translate the MFC C++ headers to Delphi32 (yes, this is
>> possible) and create any kind of plugin desired.
>You don't need to use MFC stuff to make a plugin. The Plugin SDK has a
>pure C Win32 API version that uses no MFC stuff.


I know. This is the easy part (for the converter).

But I think it is also possible to convert the MFC classes used (CInterface
etc.) to Object Pascal. I've already converted COM-interfaces to Pascal,
when Object Pascal didn't support interfaces directly and converting CObject
should be possible too. MS C++ classes and Object Pascal classes have the
same binary structure nowadays (Borland takes great care of compatibility,
because of Delphi and C++Builder). But I need to know the definition
(methods, etc.) of the base class, to make it as compatible as needed.

Using classes would greatly ease the creation of Delphi components, I think.
Creating a plugin like requested in this thread would propably be a matter
of hours, not days. Using the normal API would be like programming Windows
using the generic API (yuk) instead of components and classes.

BTW, why don't you implement real COM interfaces (as a new layer, not
replacing the existing one)? Couldn't be too hard to achieve, and would make
Moray open to any kind of language that can handle COM (i.e. implement COM
interfaces).

--
Rudy Velthuis

Post a reply to this message