> 
> [...]
> 
> Can I have feature request ?
> I think it could be interesting to somehow add automatic calculation of
> bounding/container box. 
> [...]
> Was this proposition understable ?
> 

Yes, but i'm not sure if i will add this, you won't be able to declare
things like:

#declare fn_1=IC_BBox(-1, 1) 

And this would lead to a lot of confusion i think.  I might add some
global variables to manage the relevant extends of each macro call.  This
way you could easily design the function as now and just use these global
variables in the 'contained_by{}' statement afterwards (or i could provide
a 'Create_Container()' macro doing this automatically).

Christoph

-- 
POV-Ray tutorials, IsoWood include,                 
TransSkin and more: http://www.tu-bs.de/~y0013390/  
Last updated 13 Mar. 2002 _____./\/^>_*_<^\/\.______

Post a reply to this message

Hugo wrote:
> 
> Great work and documentation, I'm sure this took some time. I'm eager to
> find out if there's a way to BLOB those mixed primitives? I suppose this
> can't be done, at least with sharp-edged objects like boxes.
> 

As ABX said this is described in the 3.5 docs.  

It is on my list for future extensions of the include file.

Christoph

-- 
POV-Ray tutorials, IsoWood include,                 
TransSkin and more: http://www.tu-bs.de/~y0013390/  
Last updated 13 Mar. 2002 _____./\/^>_*_<^\/\.______

Post a reply to this message

On Wed, 13 Mar 2002 16:28:04 +0100, Christoph Hormann <chr### [at] gmxde>
wrote:

> Yes, but i'm not sure if i will add this, you won't be able to declare
> things like:
>
> #declare fn_1=IC_BBox(-1, 1) 

when you want function then you call

#declare fn_1=IC_Box(-1, 1); // without B

when you want function with container then you call

#declare fn_1=IC_Extents( IC_BBox(-1, 1), V1, V2 );

All user have to convert statement made in your set of macros is to add letter
B in all names and enclose whole function in IC_Extents call.
IC_Extents gets 4 parameters but 2 of them are returned from IC_BBox

> And this would lead to a lot of confusion i think.

With good documentation you can avoid it

> I might add some
> global variables to manage the relevant extends of each macro call.

Note that my example maintained bounding objects instead extents. In
particular when you apply hundreds of small rotations into object then
bounding stored as Min,Max corners can grow up while bounding stored as object
is still the same size.

> This
> way you could easily design the function as now and just use these global
> variables in the 'contained_by{}' statement afterwards (or i could provide
> a 'Create_Container()' macro doing this automatically).

In this case it could be better to name it Get_Container() then direct create
contained_by{} statement. Coordinates are useful for further modifications.

ABX

Post a reply to this message

> 
> [...]
> 
> when you want function then you call
> 
> #declare fn_1=IC_Box(-1, 1); // without B
> 
> when you want function with container then you call
> 
> #declare fn_1=IC_Extents( IC_BBox(-1, 1), V1, V2 );
> 

All right, this would work.

> 
> > And this would lead to a lot of confusion i think.
> 
> With good documentation you can avoid it

But i want to keep it as simple as possible, doubling the number of macros
and having several additional helpers macros would not exactly simplify
things.  Also the CSG macros (difference, etc.) right now can take any
other function too.  The 'B' version would be more restrictive.  And
infinite shapes (only 'plane' right now) would lead to nonsense results.


Christoph

-- 
POV-Ray tutorials, IsoWood include,                 
TransSkin and more: http://www.tu-bs.de/~y0013390/  
Last updated 13 Mar. 2002 _____./\/^>_*_<^\/\.______

Post a reply to this message

On Wed, 13 Mar 2002 17:11:11 +0100, Christoph Hormann <chr### [at] gmxde>
wrote:
> But i want to keep it as simple as possible, doubling the number of macros
> and having several additional helpers macros would not exactly simplify
> things.

You can stay as is with your iso_csg.inc include file and not change anything
in your set of macros neither documentation. In fact I did everything for you.
Take a look what was changed (after moment in povray.binaries.scene-files - be
carefull - not tested). If user want simple version then he use your script as
"iso_csg.inc" if he want automatic container then he add b in letter of
include file, macro names, and addional IC_Extents call. I think it is simple
enough.

> Also the CSG macros (difference, etc.) right now can take any
> other function too.
> The 'B' version would be more restrictive.

Not, you still can use any other function, just add additional parametr as
container of this function.

> And infinite shapes (only 'plane' right now) would lead to nonsense results.

Sure, but author can aware about it in documentation ... ;-)

ABX

Post a reply to this message

On Wed, 13 Mar 2002 14:36:39 +0100, Christoph Hormann <chr### [at] gmxde>
wrote:
> I fixed a few problems since i posted the first version in p.b.s-f.  Also
> wrote some documentation and an add-on for the Povray 3.5 insert menu.
>
> http://www.tu-bs.de/~y0013390/pov/ic/index.html

Here is proposition of IC_Box macro with function returning linear distance to
the box shape.

#macro IC_Box( Start , End )
  #local Start=Start+<0,0,0>;
  #local End=End+<0,0,0>;

  #local Cx=max(Start.x, End.x);
  #local Cy=max(Start.y, End.y);
  #local Cz=max(Start.z, End.z);
  #local Dx=min(Start.x, End.x);
  #local Dy=min(Start.y, End.y);
  #local Dz=min(Start.z, End.z);

  #local Inside=function{pattern{object{box{ Start , End }}}};
    
  function(x, y, z){
    select(
      Inside(x,y,z),
      0,
      f_r(min(x-Dx,max(x-Cx,0)),min(y-Dy,max(y-Cy,0)),min(z-Dz,max(z-Cz,0))),
      max(x-Cx, y-Cy, z-Cz, Dx-x, Dy-y, Dz-z)
    )
  }
#end

ABX

Post a reply to this message

Christoph Hormann wrote:
> 
> I fixed a few problems since i posted the first version in p.b.s-f.  Also
> wrote some documentation and an add-on for the Povray 3.5 insert menu.
> 
> http://www.tu-bs.de/~y0013390/pov/ic/index.html

Christoph, I have had a look at the
code in the iso_csg.inc file.

And below are some of my suggestions
for simplifications of those macros.

I'm not sure, but from a very brief
test on my slow P100 PC at home, the
iso_csg_test02.pov file seems to
render a little bit faster with these
changes.

I have not tested all the macros below,
because I do not have patience to do
further tests with this PC (~150 PPM).

I have also added to more macros:
IC_Reorient() and IC_AxisRotate()


Tor Olav


// ===== 1 ======= 2 ======= 3 ======= 4 ======= 5 ======= 6 ======= 7

#macro IC_Transform(Fn, Trans)

  #local fn_T = function { transform { Trans inverse } }

  function {
    Fn(
      fn_T(x, y, z).x,
      fn_T(x, y, z).y,
      fn_T(x, y, z).z
    )
  }

#end // macro IC_Transform 


#macro IC_Translate(Fn, pTranslate)

  IC_Transform(
    function { Fn(x, y, z) },
    transform { translate <0, 0, 0> + pTranslate }
  )

#end // macro IC_Translate


#macro IC_Scale(Fn, vScale)

  IC_Transform(
    function { Fn(x, y, z) },
    transform { scale vScale }
  )

#end // macro IC_Scale


#macro IC_Rotate(Fn, vRotate)       // Rotate Degrees

  IC_Transform(
    function { Fn(x, y, z) },
    transform { rotate <0, 0, 0> + vRotate }
  )

#end // macro IC_Rotate


#macro IC_RotateR(Fn, vRotate)      // Rotate Radians

  IC_Transform(
    function { Fn(x, y, z) },
    transform { rotate <0, 0, 0> + vRotate*180/pi }
  )

#end // macro IC_RotateR


#macro IC_Reorient(Fn, vAxis1, vAxis2)

  IC_Transform(
    function { Fn(x, y, z) },
    transform { Reorient_Trans(vAxis1, vAxis2) }
  )

#end // macro IC_Reorient


#macro IC_AxisRotate(Fn, Angle)

  IC_Transform(
    function { Fn(x, y, z) },
    transform { Axis_Rotate_Trans(vAxis, Angle) }
  )

#end // macro IC_AxisRotate


#macro IC_Matrix(Fn, Mtrx)       // not equivalent to the matrix transform!

  IC_Transform(
    function { Fn(x, y, z) },
    transform {
      matrix <
        Mtrx[0][0], Mtrx[0][1], Mtrx[0][2],
        Mtrx[1][0], Mtrx[1][1], Mtrx[1][2],
        Mtrx[2][0], Mtrx[2][1], Mtrx[2][2],
                 0,          0,          0
      >
    }
  )

#end // macro IC_Matrix

// ===== 1 ======= 2 ======= 3 ======= 4 ======= 5 ======= 6 ======= 7

Post a reply to this message

Tor Olav Kristensen wrote:
> 
> Christoph, I have had a look at the
> code in the iso_csg.inc file.
> 
> And below are some of my suggestions
> for simplifications of those macros.
> 
> [...]

Sorry for the late reply, i had difficulty keeping track of all postings
recently.  

I tested the 'transform' version of the macros some time ago and found no
measurable difference.  I have the tendency to prefer the 'discrete'
version since you can actually see what happens... ;-)

The 'special' transforms will be added in the next release.

Christoph

-- 
POV-Ray tutorials, IsoWood include,                 
TransSkin and more: http://www.tu-bs.de/~y0013390/  
Last updated 13 Mar. 2002 _____./\/^>_*_<^\/\.______

Post a reply to this message

On Wed, 13 Mar 2002 14:36:39 +0100, Christoph Hormann <chr### [at] gmxde>
wrote:
> I fixed a few problems since i posted the first version in p.b.s-f.

Thank You, Chris. Your include files opened my eyes for simplest morphing I
have ever seen. Perhaps this was used somewhere before but I feel like
discoverer at this moment :-) Check povray.binaries.animations after moment.

All things I had to do were:
1) prepare initial appearance of object as (ISO)CSG
2) prepare final appearance of object as (ISO)CSG
3) write isosurface functions as
      (1-clock)*POV(x,y,z) + clock*v35(x,y,z)
   where  POV and v35 are isocsg combinations

Adventages:
1) Shape is desiagned as previously as simple CSG
2) No trace, interpolate, arrays, loops were involved
3) Morphing is pretty smoth

Disadventages:
Only speed probably but since inly simple functions are involved this
limitation is controled by complexity of CSG

Now I started to dream about
1) from desert to mountains landscape like in Walking With Dinosaurs
2) from seed to tree - with morphing of surface of bark
3) from youth to old age with morphing of wrinkles on the face
4) and so on

ABX

Post a reply to this message

On Wed, 13 Mar 2002 14:36:39 +0100, Christoph Hormann <chr### [at] gmxde>
wrote:
> I fixed a few problems since i posted the first version in p.b.s-f.  Also
> wrote some documentation and an add-on for the Povray 3.5 insert menu.

Could it be possible to remove optional "(x,y,z)" from all functions
declaration ? This stops from direct inlining into isosurface.

ABX

Post a reply to this message