|
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Chris B" <nom### [at] nomailcom> wrote:
> 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
So I center the left-front corner of my box at the center while in 3d max
coordinates before exporting, I can rotate easier. I feel we are getting close
to a solution on my problem. These are the values taken from PoseRay. I think
they are the values Tim was talking about in earlier posts. Which one is
important for rotation?
box_POV_geom.inc
THIS IS FROM THE BOX EXPORTED, WITH CENTER AT <0,0,0> XYZ in MAX
//Bounding Box....... from x,y,z=(-49.999,0.001,-50.001)
// to x,y,z=(50.001,100.001,49.999)
// size dx,dy,dz=(100,100,100)
// center x,y,z=(0.0009994507,50.001,-0.0009994507)
// diagonal 173.2051
--------------------------------------------------------
THIS IS FROM THE BOX EXPORTED, WITH CENTER AT <50,50,0> XYZ in MAX
//Bounding Box....... from x,y,z=(0,0,-100)
// to x,y,z=(100,100,6.123032E-15)
// size dx,dy,dz=(100,100,100)
// center x,y,z=(50,50,-50)
// diagonal 173.2051
Now here comes the cruncher again last time, If I don't get it this time either,
I will start to think something's wrong with me. THE BIG QUESTION.
If I want to rotate the box on its y axis 45 degrees, What is the formula?
Suppose box is declared
#declare BOX = object { box_ scale <0.01,0.01,0.01> }
and it was located at translate <-50,10,0> before we will rotate it.
You should use the first centered sample above <0,0,0>, easier I think .
Your answer to this question should nail it for me. I couldn't be more greatful
for all your help so far. I know it's about centering something at the (some)
center of something's center, these centers are what gets me lost in all this.
PS: I don't care much about mesh rotations, cause they rotate anyhow, a little
off but acceptable. Cabinets and wall must rotate precisely. A chair rotated
around a table, a little off is not even noticable at first , see what I mean.
This may sound a little unprofessional but , right now my cabinet rotation
problem is monumental next to a mesh's rotation. All cabinets and walls are made
from #include "box_POV_geom.inc"
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|