> 1- // the angled cabinet
> object {
>   CABINET
>   translate <0,0,60> // place front-left-bottom corner on origin
> 1- Why do we translate to <0,0,60>, what if I want to rotate around right 
> front
> corner then what would this value be ? I think this point needs 
> elaboration.
> Did you multiply <-0.5,-0.5,0>*<x,x,x>?

The meshes are 100 wide by 100 tall by 100 deep.
So after aligning everything at that size, it's all scaled
by scale <0.5,0.75,0.6>... so that's
<100,100,-100>*<0.5,0.75,0.6> = <50,75,-60>
which is the coordinates of the top-right-forward
corner, but it's also the dimensions, since the opposite
corner is on <0,0,0>.

The reason it's translated by <0,0,60> is to put the
left-front corner on the origin for rotatation around
the Y axis.

If you wanted to rotate arount the front-right corner,
then you'd translate by <-50,0,60>, putting the
front-right corner on the origin before rotating.
Then you place it with another translation.

> 2- Declaring a Cabinet Union, then just copying and placing them on the 
> scene is
> brilliant. That's the route I want to go for each similar object. But each
> cabinet may have different texture, handle, door model applied to it.
> So in
> // the left cabinet
> object {
>   CABINET
>   translate <0,0,0>
>   rotate <0,0,0>
>   translate <0,10,0> // raise bottom of cabinet to kick height
> }
> How should I proceed to reflect these different characteristics in the 
> object?

Yeah, you probably will end up with a union for every unique cabinet,
that's normal. You'll need to number them or something. You might
end up with different shelving options for the cases too? It doesn't
matter much, with the doors closed you can't see the inside.
If you plan to open any of the doors, then you should keep track
of the hinge location, that way you can move the cabinet so that
the Y axis lines up along the hinges, rotate open the door (in the union)
and then place it back.

The more complicated your meshes get the harder it'll be to determine
where the corners of your mesh object are. It's worth the small amount
of time it takes to try to line up a corner with the origin in your
modeling package. That way you can just import the meshes,
and then place them into a union without having to manually
re-align each part.

Post a reply to this message

"mysdn" <kam### [at] hotmailcom> wrote in message 
news:web.4a409e00cfb6d60e4e47a1b0@news.povray.org...
> Tim,
> I don't think I can use
> #declare CABINET = union { ...
> because as I said each cabinet may have different characteristics, even no
> characteristics such as no door, no handle, then our "declare CABINET" 
> would be
> useless, cause it defines a solid , fixed model. We need an adjustable 
> model
> definition, with following specifications adjusted diffrently for each 
> cabinet.
>
> location
> scale
> case texture
> door texture
> handle texture
> door model
> handle model
>
> all these may be diffrent for each cabinet, I think we should construct a
> separate Union for each cabinet, What do you think?
>

One approach could be to use a macro. The example below adds 3 different 
cabinets, generated based on variable settings. Each variable has a default 
value that is set at the start of the macro.  The first macro call generates 
the default cabinet. The second uses a Cyan colored door with the door half 
open. The third has no door.

You mentioned a 2D application at the start of this thread. This would 
enable you to use a 2D graphics application to define a layout for the 
cabinets. Your application could pick up the positions, sizes and 
orientations from a 2D vector image and use this POV-Ray macro (which you 
can make as sophisticated as you like) to generate cabinets with the 
required specifications. I did something similar a few years back using SVG 
graphics to define the layout of a some houses 
(http://www.geocities.com/povstairs/povhouse/).

camera {location <-1, 1.2, -1> look_at <0.6,0.3,0>}
light_source {<2,20,-4> color rgb 2}

#macro Cabinet ()

  // Default Cabinet Variables
  #ifndef (Height) #declare Height = 0.9; #end
  #ifndef (Width)  #declare Width  = 0.6; #end
  #ifndef (Depth)  #declare Depth  = 0.6; #end
  #ifndef (Thickness)  #declare Thickness  = 0.012; #end
  // Default Door Variables
  #ifndef (Door_Thickness) #declare Door_Thickness  = 0.02; #end
  #ifndef (Door_OpenAngle) #declare Door_OpenAngle  = 0;    #end
  #ifndef (HasDoor)        #declare HasDoor  = true;        #end

  // Default Textures
  #ifndef (Cabinet_Texture)
    #declare Cabinet_Texture = texture {pigment {rgb 1}}
  #end
  #ifndef (Door_Texture)
    #declare Door_Texture = texture {pigment {rgb <1,1,0>}}
  #end

  union {
    // Cabinet
    difference {
      box {<0,0,0><Width,Height,Depth>}
      box {<Thickness,0.15,-0.001>
           <Width,Height,Depth>-Thickness
      }
      texture {Cabinet_Texture}
    }
    // Door
    #if (HasDoor)
      box {<0,0,0><Width,Height,-Door_Thickness>
        texture {Door_Texture}
        rotate y*Door_OpenAngle
      }
    #end
  }

#end

// Add 3 cabinets to the scene by calling the macro

// Default Cabinet
object {Cabinet()}

// Custom Cabinet
#declare Width = 0.8;
#declare Door_Texture = texture {pigment {rgb <0,1,1>}}
#declare Door_OpenAngle  = 45;
object {Cabinet() rotate y*45 translate 0.62*x}

// Doorless Cabinet
#declare Width = 0.3;
#declare HasDoor  = false;
object {Cabinet() translate -0.32*x}


Regards,
Chris B.

Post a reply to this message

mysdn wrote:

> on second thought, I don't think I can use
> // cabinet
> #declare CABINET = union {
>    // case
>    object{
>       box_ //
> because as I said each cabinet may have different characteristics

As Chris already said you can use a macro for this. In addition
to his suggestion, note that macros can have parameters and do not
need to use global variables. From a software engineering view that
would be preferred because it avoids conflicts with other macros
or variable names you wish to use for something else (the name
of a parameter is *local* to a macro, as is a variable which is
declared using #local instead of #declare within the macro):

   #macro Cabinet(Width,Height,Depth,Thickness,
                  Door_Thickness,Door_OpenAngle, HasDoor
                  Cabinet_Texture, Door_Texture)
   union
   {
     // Cabinet
     difference
     {
       box {<0,0,0><Width,Height,Depth>}
       ...
     }
   }

   #end

You would then need to call it like

   Cabinet(0.6,0.9,0.6,0.012,0.02,0,true)


To not always have to specify all parameters, you
can then specialize this with mechanisms like

   #macro CabinetModelA(Width,Height,Depth,Door_OpenAngle)
     #local T_DOOR    = texture {...}
     #local T_CABINET = texture {...}
     Cabinet(Width,Height,Depth,0.012,0.02,Door_OpenAngle,true,
             T_DOOR,T_CABINET)
   #end

   #macro CabinetModelB(Width,Height,Depth)
     #local T_DOOR    = texture {...}
     #local T_CABINET = texture {...}
     Cabinet(Width,Height,Depth,0.012,0.02,0,false,
             T_DOOR,T_CABINET)
   #end

   CabinetModelA(1,1.5,0.4,30)

   CabinetModelB(0.5,0.7,0.5)


Finally, you might wish to have a look at some existing
scene source code before losing yourself in the details of
your own. E.g., have a look at IRTC images such as those under
http://www.irtc.org/irtc/irtc?_n&pg=ViewSummary&id=StillImages_September-October2006
Many images provide a "source" link (and most of those are
done with POV-Ray). This helps prevent reinventing the wheel.
Reusing an object is useful, but not exactly "brilliant" ;)

Post a reply to this message

"Christian Froeschlin" <chr### [at] chrfrde> wrote in message 
news:4a40e339$1@news.povray.org...
> ...  note that macros can have parameters and do not
> need to use global variables. From a software engineering view that
> would be preferred because it avoids conflicts with other macros
> or variable names you wish to use for something else

I ceratinly agree that in many programming languages, other approaches would 
be preferable, but POV-Ray is a bit limited in this respect and the use of 
global variables to control macros that require large numbers of controls is 
the best approach I've been able to come up with in POV-Ray from a software 
engineering perspective.

The main advantage with using variables in this way is that you can specify 
just the variables you need, whereas to accommodate all desired permutations 
using the 'MacroA, MacroB etc' technique could require thousands of wrapper 
macros.

In this instance, to parameterise drawers, doors, door-handles, the cabinet 
itself, shelves, kickboards and worktops, each with an average of 6 
parameters for dimensions, colors, openness, handedness etc, you could 
pretty quickly get up to 40 or 50 settings, which, IMO, becomes difficult 
and messy to manage with parameters. OTOH, in this particular case, if the 
macro call is always to be written by an external application then I admit 
that this could still be viable.

With the object collection it was also discovered that the use of local 
variables didn't guarantee you won't get naming collisions, because certain 
identifiers always have a global context, whereas adhering to simple naming 
standards, for both local and global variables, seem to readily avoid all 
those sorts of problems.

Regards,
Chris B.

Post a reply to this message

Thanks for all comments again, everything said will be taken into consideration,
I don't know when I will have my aha moment, specially on the subject of
rotations, because that subject pushes my limits.
In the zip file I attached you'll find a complete kitchen ready to render in
povray. Then you'll see exactly what I'm trying to do and what would be the
best way to go about it. This sample kitchen was produced by a C# app that
writes SDL files for POV.
As you can see in the sample kitchen I already have a working algorithm in my C#
app for producing solid, working .pov files.

The first reason I came to this forum was to ask about rotations, now it's more
like, am I doing all this the best possible way? In a design not all objects
are cabinets, it may be sinks, lamps, couches these are mesh objects though.
But now we talk about cabinets.

I produce all my cabinets from box_geom which is 100x100x100 in xyz size
representing 100 cm, cause then I divide it by 0.01, so that I can multiply it
by eg. 60 representing 60 cm, this for example can be a cabinets width or
whatever, in short this way of dimensioning lets me work in mm.

Any comments on how to approach producing this kitchen from SDLs, possibly you
would suggest a Union for each cabinet?

http://www.optimadekor.com/yesdownload/my_kitchen.zip


PS: in the zip the jpeg "2D design" tells the same story in 2D.

Post a reply to this message

"mysdn" <kam### [at] hotmailcom> wrote in message 
news:web.4a40f8fccfb6d60e4e47a1b0@news.povray.org...
>
> The first reason I came to this forum was to ask about rotations, now it's 
> more
> like, am I doing all this the best possible way? In a design not all 
> objects
> are cabinets, it may be sinks, lamps, couches these are mesh objects 
> though.
> But now we talk about cabinets.
>

There's not necessarily a universally 'best possible' way. If you've got the 
objects you need or you've got a way that you're comfortable with producing 
them (e.g. a modelling tool) in the various configurations you need, then 
there's no compelling need to change. The technique you've got may well be 
the best way for you.

Currently you seem to be using meshes througout. This has the advantage of 
being closer to other formats in case you want to interface to other 
renderers or any modeller or 3D display applications in the future. OTOH 
Using POV-Ray primitives, such as boxes, spheres etc could make the POV file 
easier to read and more compact, but that depends whether you need anyone to 
read it. If you are simply using POV-Ray to render from your application, 
then those considerations may not be important.

> I produce all my cabinets from box_geom which is 100x100x100 in xyz size
> representing 100 cm, cause then I divide it by 0.01, so that I can 
> multiply it
> by eg. 60 representing 60 cm, this for example can be a cabinets width or
> whatever, in short this way of dimensioning lets me work in mm.
>
> Any comments on how to approach producing this kitchen from SDLs, possibly 
> you
> would suggest a Union for each cabinet?
>

You can use a union to assemble the components of the cabinet into a single 
unit if you wish. One reason you may like to do this would be to be able to 
position and orient the cabinet as a single unit, rather than having to work 
out the tranformations required for each separate part of the cabinet. This 
is only if it makes it easier for you to develop though. If you are more 
comfortable keeping the components separate then I don't see any particular 
need to join them together using a CSG union.

Regards,
Chris B.

Post a reply to this message

"Tim Attwood" <tim### [at] anti-spamcomcastnet> wrote:

< The more complicated your meshes get the harder it'll be to determine
< where the corners of your mesh object are. It's worth the small amount
< of time it takes to try to line up a corner with the origin in your
< modeling package. That way you can just import the meshes,
< and then place them into a union without having to manually
< re-align each part.

I use 3ds max and always center my models on XYZ 0,0,0 respectively on absolute
world coordinates of max. I hope that's the right thing to do.

the box_geom you saw in samples was also exported from max with same settings

Post a reply to this message

"Chris B" <nom### [at] nomailcom> wrote:

> You mentioned a 2D application at the start of this thread. This would

Yes, a 2D app is going to write the whole SDL file, so it needs to be automated.
and I love this macro idea, if I can get it to actualy work.

The macro idea seems like the key but it must be parameterized for different
types cabinets, I suppose there would be upto 100 macros for cabinets. Other
objects in my scene don't need macros defined for them cause they are mesh
objects. Mostly, this is a cabinet application and it will be cabinets causing
the biggest headaches. Yes Froeschlin suggested  a parameterized macro but he
left it empty inside, could you guys fill in some more blanks in that macro?
I need some variables set inside the macro, some variables set at object
declaration, meaning when placed in the scene.

macro should use the box_POV_geom.inc I exported from Max, scaled to
<0.01,0.01,0.01> so that we can multiply it by eg. 50 (that will be 50 cm)
sample cabinet's width 50, height 75, depth 60 cm
for textures I use jpegs

the case of cabinet should be constructed by 5 pieces of box_POV_geom.inc, not
CSG. Because I want to texture side panels and top , bottom differently.
the door also constructed as 6th piece from box_POV_geom.inc
the handle is a mesh I have, you can use box_POV_geom.inc, just to show

Variables inside macro, all values passed to the macro at invoke time:

Scale xyz
rotate xyz (maybe this can be left outside the parameter list and set from call)
case_texture
door_texture
shelf_texture
handle_texture
shelfCount
hasDoor
hasCountertop
hasToe
hasTopMolding
hasBottomMolding
hasHandle
handle_right_left (or hinge)
handle_Pos   (handle may be anywhere on cabinet)

Can you comment the code some, especially the variables, declarations?
I guess I can put the macro in a text file, place it in POV folder and call it
from the SDL, right?

It will certainly clarify a lot. I thank you all from the bottom of my heart.
I don't want you people to do my work for me, I'm trying to learn, cause with
hundreds of macros I need, no one can do it for me? just teach me if you will.
It seems like I only need one fully working macro. Then I 'll take it form there
like a thunder.

Post a reply to this message

Hi,
I got most of the macro working, only a few problems, sorry for sounding really
stupid. My previous request for a macro sample is rendered obsolete by this
post. Cause I got a macro (Chris B's sample) working even though still missing
a lot of functionality.

1- I can't pass the texture names to macro as a parameter
2- I need another Union inside Cabinet Union for door, the door and the handle
should be another Union inside Cabinet Union. So when we open the door the
handle moves along. Right?
3- the handle may be on the right or left of the door , how do we handle that?
   thus the hinge place changes, thus the door opens to a different side....

that's it for now I'm working on it, these 3 are all I'm stuck on right now.

PS: in the future I'll need a challenging macro for angled cabinets. Remember
the angled wall, well what if it needs a cabinet placed in its angled corner.
That cabinet should be angled accordingly in 2 pieces, single door. To
understand what I'm saying , draw a straight line 50 cm, at right side draw
another line 40 cm at 40 degrees rotated towards yourself, now make that into a
cabinet on paper.

Thanks a million


------------ the code I got working--------improvised Chris B's code
// How does it look?

//#include "Cabinet.inc"

camera {location <-1, 1.2, -1> look_at <0.6,0.3,0>}
light_source {<2,20,-4> color rgb 2}


#macro Cabinet (Width,Height,Depth,HasDoor,Door_OpenAngle)


  #ifndef (Thickness)  #declare Thickness  = 0.012; #end
  // Default Door Variables
  #ifndef (Door_OpenAngle) #declare Door_OpenAngle  = 0;    #end
  #ifndef (HasDoor)        #declare HasDoor  = true;        #end

  // Default Textures
  #ifndef (Cabinet_Texture)
    #declare Cabinet_Texture = pigment {image_map {jpeg "yo_toprak"}scale 1 }
  #end
  #ifndef (Door_Texture)
    #declare Door_Texture = pigment {image_map {jpeg "A366_abanoz"}scale 1 }
  #end

  union {
    // Cabinet
    difference {
      box {<0,0,0><Width,Height,Depth>}
      box {<Thickness,0.15,-0.001>
           <Width,Height,Depth>-Thickness
      }
      texture {Cabinet_Texture}
    }
    // Door
    #if (HasDoor)
      box {<0,0,0><Width,Height,-0.02>
        texture {Door_Texture}
        rotate y*Door_OpenAngle
      }
    #end
  }

#end


// Add 3 cabinets to the scene by calling the macro

// Default Cabinet
#declare Cabinet_Texture = pigment {image_map {jpeg "yldz_yesiltarra"}scale 1 }
#declare Door_Texture = pigment {image_map {jpeg "A366_abanoz"}scale 1 }
object {Cabinet(0.5,0.75,0.6,true,0) rotate y*0 translate 0.0*x translate 0.10*y
translate 0.15*z}



// Custom Cabinet
#declare Cabinet_Texture = pigment {image_map {jpeg "yo_toprak"}scale 1 }
#declare Door_Texture = pigment {image_map {jpeg "A366_abanoz"}scale 1 }
object {Cabinet(0.5,0.75,0.6,true,45) rotate y*45 translate 0.62*x translate
0.10*y translate 0.15*z}

// Doorless Cabinet
#declare Cabinet_Texture = pigment {image_map {jpeg "yo_toprak"}scale 1 }
#declare Door_Texture = pigment {image_map {jpeg "A366_abanoz"}scale 1 }
object {Cabinet(0.35,0.75,0.6,true,0) rotate y*0 translate -0.38*x translate
0.10*y translate 0.15*z}

Post a reply to this message

"mysdn" <kam### [at] hotmailcom> wrote in message 
news:web.4a41d72acfb6d60e4e47a1b0@news.povray.org...
> Hi,
> I got most of the macro working, only a few problems, ..
>
> 1- I can't pass the texture names to macro as a parameter

Yes you can, but it's usually best to #declare a texture and use it's name 
as a parameter:
#declare MyTexture = texture {pigment {rgb <1,1,0>}}
MyMacro(0,1,MyTexture,2,3)


> 2- I need another Union inside Cabinet Union for door, the door and the 
> handle
> should be another Union inside Cabinet Union. So when we open the door the
> handle moves along. Right?

You can nest unions within one another. Yes it's easiest to union the handle 
to the door before you move the back left or right edge of that union to the 
origin to rotate (open) it.


> 3- the handle may be on the right or left of the door , how do we handle 
> that?
>   thus the hinge place changes, thus the door opens to a different 
> side....

I would recommend having a 'HingeSide' setting of '1' for right, or '-1' for 
left. Then, for the door handle you can do something like
translate <-HingeSide*0.4*Width,HandleHeight,DoorThickness>
// Note the '-' sign to bring the handle to the opposite side to the hinge.

then with the union of the door and handle you'd have something like:
translate <HingeSide*Width,0,0>
rotate y*Door_OpenAngle
translate <-HingeSide*Width,0,0>


Regards,
Chris B.

Post a reply to this message