"mysdn" <kam### [at] hotmailcom> wrote in message 
news:web.4a415687cfb6d60e4e47a1b0@news.povray.org...
> "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.
>

There's no absolute right or wrong, but being too rigorous about centreing 
things can be problematic. If you centre the cabinet base and you 
independently centre the segment of worksurface to go on top of it then, 
because the two are a different depth, you have a slightly more complicated 
calculation to do to align the two (ie it takes longer to code, test and 
fix).

Other examples: Centreing a model of a door handle makes it slightly more 
difficult to align it to the front of the door than if you model it with the 
point at which it connects to the door at the origin. Vertically centreing 3 
different sinks doesn't seem to be as logical as modelling them so that the 
height at which they connect with the worksurface is consistent across all 
your sink models. It might be easier to position your cabinets and slot them 
together if the back left corner of a cabinet was always in a consistent 
position.

It may be worth taking account of such assembly requirements when 
considering what to use as your modelling datum for each element of the 
construction.

Regards,
Chris B.

Post a reply to this message

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

> It might be easier to position your cabinets and slot them
> together if the back left corner of a cabinet was always in a consistent
> position.

What do you mean by a consistent position?

Wouldn't this position be <0,0,0> for each object then translated and rotated to
proper place within the Unions in the macro I'm trying to create.
Thank you for your input, it's making a big big difference with every post.

How can I incorporate a handle.inc in below Union?

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


  union {
    // Cabinet

    box {<0,0,0><Width,Height,Depth> pigment {image_map {jpeg
Cabinet_Texture}scale 0.5 } finish {phong 1 ambient 0.6 reflection 0}}



    // Door
    #if (HasDoor)
      box {<0,0,0><Width -1 ,Height -1,2> pigment {image_map {jpeg
Door_Texture}scale 0.5 }// finish {phong 1 ambient 0.6 reflection 0}}

        //texture {Door_Texture}
        rotate y*Door_OpenAngle
        translate z*60
      }
    #end

     //Handle
     /*
    #if (HasHandle)//INSTEAD OF box A HANDLE.INC (mesh) NEEDS TO BE DEFINED HERE
      box {<0,0,0><Width -1 ,Height -1,2> pigment {image_map {jpeg
Door_Texture}scale 1 } //finish {phong 1 ambient 0.6 reflection 0}}

        //texture {Door_Texture}
        rotate y*Door_OpenAngle
        translate z*60
      }
    #end
       */





  }

#end

PS: I'm thinking about opening a thread on macros, this has become an issue of
creating hundreds of macros for me.

Post a reply to this message

"mysdn" <kam### [at] hotmailcom> wrote in message 
news:web.4a423009cfb6d60e4e47a1b0@news.povray.org...
> "Chris B" <nom### [at] nomailcom> wrote:
>
>> It might be easier to position your cabinets and slot them
>> together if the back left corner of a cabinet was always in a consistent
>> position.
>
> What do you mean by a consistent position?
>
> Wouldn't this position be <0,0,0> for each object then translated and 
> rotated to
> proper place within the Unions in the macro I'm trying to create.
> Thank you for your input, it's making a big big difference with every 
> post.
>

Yes, but in the modeller you need to decide which bit of a model is 
positioned at <0,0,0>.
If you centre two differently shaped door handle models so that their 
geometric centres are at <0,0,0>, then you have to perform different 
translations to fit each of them to a door. It's less work for you to model 
all handles so that the point at which they are attached to the door is at 
<0,0,0>, then all handles will be translated by the same amount to attach 
them to the doors. The same is true of taps and a similar logic can be 
applied with other fittings and fixtures to work out the optimum point on 
the model to position at <0,0,0>.


> How can I incorporate a handle.inc in below Union?

One way would be to add the name of the style of the handle into the file 
name, then pass the style name into the macro.
For example, if you pass in a style name of "roundgold" and the include file 
'handle_roundgold' contains the declaration for:

#declare Handle = mesh2 { ....}

Then you could have something like:

#macro Cabinet
(Width,Height,Depth,HasDoor,Door_OpenAngle,Cabinet_Texture,Door_Texture,HandleStyle)

#include concat("handle_",HandleStyle,".inc")

union {
    // Cabinet
    ... snip ...
    // Door
   #if (HasDoor)
       ... snip ...

      //Handle
      #if (HasHandle)
           object {Handle texture {...}}
      #end
   #end
}

Note that by nesting the '#if' for the handle inside the '#if' for the door 
you avoid having a handle with no door.


> PS: I'm thinking about opening a thread on macros,

That's probably a good idea, this thread has strayed a bit off the original 
topic.

> this has become an issue of
> creating hundreds of macros for me.

Personally I'd tend to try to avoid having hundreds of macros if it were me, 
but that's just down to programming style.

Regards,
Chris B.

Post a reply to this message

> 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?

Not bad =)

Here's a rewrite demonstrating passing values to a macro by global
variables. There's nothing wrong with using parameters and ifndef,
but if you use one of the ifndef values, then it will persist to the next
macro call, which is can cause odd behavior.

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

// macro to initialize default values
#macro NewCabinet()
   #declare Thickness = 0.012;
   #declare Door_OpenAngle  = 0;
   #declare HasDoor  = true;
   #declare Cabinet_Texture = pigment {image_map {jpeg "yo_toprak"}}
   #declare Door_Texture = pigment {image_map {jpeg "A366_abanoz"}}
   #declare Width = 0.5;
   #declare Height = 0.75;
   #declare Depth = 0.6;
   #declare HasHandle = false;
   #declare Handle_Object = sphere {<0,0,-0.05>,0.05};
   #declare Handle_Texture = pigment {rgb <1,1,1>};
   #declare Handle_At = <0.15,0.6,-0.02>;
#end

// build a Cabinet
#macro Cabinet()
  union {
    // case
    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
    // handle
    #if (HasHandle)
      object {
         Handle_Object
         texture {Handle_Texture}
         translate Handle_At
         rotate y*Door_OpenAngle
      }
    #end
  }
#end

// Add 3 cabinets to the scene by calling the macro
// Default Cabinet
NewCabinet()
#declare Cabinet_Texture = pigment {image_map {jpeg "yldz_yesiltarra"}scale 
1 }
#declare Door_Texture = pigment {image_map {jpeg "A366_abanoz"}scale 1 }
object {Cabinet() rotate y*0 translate 0.0*x translate 0.10*y
translate 0.15*z}

// Custom Cabinet
NewCabinet()
#declare Cabinet_Texture = pigment {image_map {jpeg "yo_toprak"}scale 1 }
#declare Door_Texture = pigment {image_map {jpeg "A366_abanoz"}scale 1 }
#declare Door_OpenAngle = 45;
object {Cabinet() rotate y*45 translate 0.62*x translate
0.10*y translate 0.15*z}

// Doorless Cabinet
NewCabinet()
#declare Cabinet_Texture = pigment {image_map {jpeg "yo_toprak"}scale 1 }
#declare Door_Texture = pigment {image_map {jpeg "A366_abanoz"}scale 1 }
#declare Width = 0.35;
#declare HasDoor = false;
object {Cabinet() rotate y*0 translate -0.38*x translate
0.10*y translate 0.15*z}

Post a reply to this message

Chris B wrote:

> The main advantage with using variables in this way is that you can 
> specify just the variables you need

Yes, I reckoned you used that mechanism for more convenient
default values. However, it's not quite true you only need to
specify the variables you need: you also need to reset those
which have been modified for some previous invocation of
the macro, and you may not always be aware of those.

That problem could be prevented by having two macros for
each object, the first one just resetting the defaults:

#macro Begin_Cabinet()
   #declare WIDTH = 0.6
   ...
#end

#macro End_Cabinet()
   union
   {
     ...
   }
#end

Begin_Cabinet()
#declare WIDTH = 0.7
End_Cabinet()

It would also remove the need for all those #ifndef's.

Post a reply to this message

"Christian Froeschlin" <chr### [at] chrfrde> wrote in message 
news:4a42abde$1@news.povray.org...
> Chris B wrote:
>
>> The main advantage with using variables in this way is that you can 
>> specify just the variables you need
>
> Yes, I reckoned you used that mechanism for more convenient
> default values. However, it's not quite true you only need to
> specify the variables you need: you also need to reset those
> which have been modified for some previous invocation of
> the macro, and you may not always be aware of those.
>

Any identifiers defined within the macro that shouldn't persist across macro 
calls should be defined using #local rather than #declare.

It's true that any global values that you set before calling the macro the 
first time will persist across macro calls (unless you undef them), but you 
should generally be aware of what those are, because you'll usually have set 
them explicitly yourself. For things like the cabinet height, the panel 
thickness, handle type etc. this is mostly a good thing, as you can set them 
once at the top of your scene file and then generate a whole set of cabinets 
conforming to the same style. You only need to adjust the width and other 
unit-specific attributes between macro calls (door handedness, whether 
there's a sink or hob in the worksurface etc.).

There are a few situations where the macro could set a default in one 
invocation that you don't want to carry across into the next invocation. 
Where I've published macros for use by others, I've usually therefore 
included an Undef macro that can be used to reset all of the variable 
settings for which there are default values declared. This gives you the 
option of using the POV-Ray #undef command to override just that one default 
value (if you know what it's called), or calling my Undef macro to reset 
everything before the next sequence of macro calls (to be on the safe side).

For example, the Rope macros include a Rope_Undef macro. You can call that 
macro between any two Rope macro calls to Undef all of the values, so that 
you can start afresh. If the same were done here you could have a kitchen 
showroom, generating 10 units for one kitchen exhibit, then calling the 
Cabinet_Undef macro before generating 10 units in a different style for the 
next kitchen exhibit.

P.S. The #ifndef statements are really very quick to add at the end of the 
development process. Using the Windows POV-Ray editors 'columnar' editing 
feature it just takes a few seconds more work. The Undef macro is also very 
quick to create as it's mostly just a copy of the #ifndef statements with 
#ifndef changed to #ifdef and #declare changed to #undef (and the values 
removed).


> That problem could be prevented by having two macros for
> each object, the first one just resetting the defaults:
>
> #macro Begin_Cabinet()
>   #declare WIDTH = 0.6
>   ...
> #end
>
> #macro End_Cabinet()
>   union
>   {
>     ...
>   }
> #end
>
> Begin_Cabinet()
> #declare WIDTH = 0.7
> End_Cabinet()
>
> It would also remove the need for all those #ifndef's.

This comes down a little to personal preference, but I'd argue that the 
#ifndef approach makes it a little easier to generate a complete set of 
cabinets in a consistent style.

The technique you've illustrated also seems to make it more difficult to 
handle what I could call 'dependant' defaults. For example, in the Rope 
macros, the strand thickness defaults to half the rope thickness for twisted 
ropes and one third the rope thickness for braided ropes (which have twice 
the number of strands). If you only set the type of rope after calling 
Begin_Rope you don't have enough info to be able to set the default strand 
thickness within Begin_Rope.


Regards,
Chris B.

Post a reply to this message

"Chris B" <nom### [at] nomailcom> wrote:
> Yes, but in the modeller you need to decide which bit of a model is
> positioned at <0,0,0>.
> If you centre two differently shaped door handle models so that their
> geometric centres are at <0,0,0>, then you have to perform different
> translations to fit each of them to a door. >

 You lose me when you say "geometric centres are at <0,0,0>"

Who, What decides centres to be at <0,0,0>, when why how,

If I can figure out the answer to these, I will have rotation by the balls.

Grateful =)

Post a reply to this message

"mysdn" <kam### [at] hotmailcom> wrote in message 
news:web.4a436039cfb6d60e4e47a1b0@news.povray.org...
> "Chris B" <nom### [at] nomailcom> wrote:
>> Yes, but in the modeller you need to decide which bit of a model is
>> positioned at <0,0,0>.
>> If you centre two differently shaped door handle models so that their
>> geometric centres are at <0,0,0>, then you have to perform different
>> translations to fit each of them to a door. >
>
> You lose me when you say "geometric centres are at <0,0,0>"
>
> Who, What decides centres to be at <0,0,0>, when why how,
>

It's you. You do it!  Honest :-)

I've tried to explain further below, but it may be that others can explain 
differently in a way that may suit you better. So if anyone can phrase it 
differently it's probably worth posting.  I think that understanding this is 
the key to you understanding the answer to your original 
translation/rotation question.


Whenever you add a vertex into an object that you are modelling, for example 
in 3D Max, the position of that vertex is defined relative to an origin 
(position <0,0,0>). This could be in the Global coordinate system of the 
modeller, or some modellers allow you to define a Local coordinate system 
for each of the different objects that you have added into the model.

Also, whenever you add a line into a 2D drawing it is relative to some 
origin (position 0.00, 0.00), which is usually the top left or bottom left 
of the screen or page (though some applications place it in the middle of 
the page). Sometimes you don't see this in a 2D graphics application because 
it's handled behind the scenes, but any decent 2D or 3D application will 
have an option to display something to indicate the actual coordinates and 
then you can see where the origin is.

When you export an object from 3D Max, you need to know how the origin of 
the coordinate system in the generated file relates to your object. I don't 
know if an object is always written out using the Global coordinate system 
or whether 3D Max has an option to allow you to export an object using Local 
coordinate system coordinates. If you can't tell, then translating and 
rotating it, as necessary to map to the coordinate system used by your 2D 
software, becomes mind-bogglingly difficult (or degenerates to a matter of 
guesswork (sometimes called 'successive approximation')).

If you are able to control where the origin is, relative to your 3D models 
and your 2D plan, then life becomes an awful lot easier. Particularly when 
you come to mapping the 3D objects to your 2D plan and assembling all the 
bits in POV_Ray. even if you can't control the positioning of the origin you 
still need to know where the origin is to get the translations and rotations 
working right.

Regards,
Chris B.

Post a reply to this message

"Chris B" <nom### [at] nomailcom> wrote:
> It's you. You do it!  Honest :-)

Chris, I always use the box_POV_geom.inc, it's a primitive box shape sized
100X100X100 cm in 3d max and exported to PoseRay for use in POV.
it has following headers, which lines below I need to pay attention to rotate
correctly.
I know Tim Attwood explained the math necessary, but I guess I need my nose
rubbed in it. Thank you.
-----------------------------------
//Materials
#include "box_POV_mat.inc"

//Geometry
#declare box_unnamed_material_=mesh2{
vertex_vectors{
26,
<-49.999,-49.999,0.001>,
<-49.999,50.001,0.001>,
<50.001,50.001,0.001>,
<50.001,-49.999,0.001>,
<-49.999,-49.999,100.001>,
<50.001,-49.999,100.001>,
<50.001,50.001,100.001>,
<-49.999,50.001,100.001>,
<-49.999,-49.999,0.001>,
<50.001,-49.999,0.001>,
<50.001,-49.999,100.001>,
<50.001,-49.999,100.001>,
<-49.999,-49.999,100.001>,
<-49.999,-49.999,0.001>,
<50.001,50.001,0.001>,
<50.001,-49.999,100.001>,
<50.001,50.001,0.001>,
<-49.999,50.001,0.001>,
<-49.999,50.001,100.001>,
<-49.999,50.001,100.001>,
<50.001,50.001,100.001>,
<50.001,50.001,0.001>,
<-49.999,50.001,0.001>,
<-49.999,-49.999,100.001>,
<-49.999,-49.999,100.001>,
<-49.999,50.001,0.001>
}
normal_vectors{
30,
<0,0,-1>,
<0,0,-1>,
<0,0,-1>,
<0,0,-1>,
<0,0,1>,
<0,0,1>,
<0,0,1>,
<0,0,1>,
<0,-1,0>,
<0,-1,0>,
<0,-1,0>,
<0,-1,0>,
<0,-1,0>,
<0,-1,0>,
<1,0,0>,
<1,0,0>,
<1,0,0>,
<1,0,0>,
<0,1,0>,
<0,1,0>,
<0,1,0>,
<0,1,0>,
<0,1,0>,
<0,1,0>,
<-1,0,0>,
<-1,0,0>,
<-1,0,0>,
<-1,0,0>,
<-1,0,0>,
<-1,0,0>
}
uv_vectors{
26,
<1,0>,

Post a reply to this message

"mysdn" <kam### [at] hotmailcom> wrote in message 
news:web.4a4480b9cfb6d60e4e47a1b0@news.povray.org...
> "Chris B" <nom### [at] nomailcom> wrote:
>> It's you. You do it!  Honest :-)
>
> Chris, I always use the box_POV_geom.inc, it's a primitive box shape sized
> 100X100X100 cm in 3d max and exported to PoseRay for use in POV.
> it has following headers, which lines below I need to pay attention to 
> rotate
> correctly.
> -----------------------------------
> //Materials
> #include "box_POV_mat.inc"
>
> //Geometry
> #declare box_unnamed_material_=mesh2{
> vertex_vectors{
> 26,
> <-49.999,-49.999,0.001>,

In this instance the geometric centre of the object is centred at the 
origin. If you move the box in 3DMax so that one corner is at the origin 
instead, you may find it easier to line everything up. This doesn't make a 
very big difference with a box as the calculations are not very complex, but 
it can make a big difference when you start to model door-handles, sinks, 
taps and other asymmetrical objects.

> I know Tim Attwood explained the math necessary, but I guess I need my 
> nose
> rubbed in it. Thank you.

I hope it doesn't come across as if I'm trying to rub your nose in it. I was 
attempting to stress stuff, but still keep the conversation light, though I 
know I quite often miss my target when attempting this.


Regards,
Chris B.

Post a reply to this message