|
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
We have difference.
We have inverse objects.
Can I plot, say a wall, and then subtract away doorways with negative objects?
It would vastly simplify things to be able to define a room - an addition with
said negative doorway, and automagically open a doorway to that room when it's
added into the scene - rather than having to go search through the code ... or
an include file ... to find out where to insert the right box in a difference
statement.
Just a thought.
It would be cool to make things go through walls in animations with a large
negative-space sphere surrounding a smaller "positive" sphere.
Or a black hole traveling through space.
Or the invisible man walking through a cloud of smoke...
Post a reply to this message
|
|
| |
| |
|
|
From: Warp
Subject: Re: ex post facto difference - "negative" objects
Date: 27 Aug 2013 15:59:13
Message: <521d0511@news.povray.org>
|
|
|
| |
| |
|
|
Bald Eagle <cre### [at] netscapenet> wrote:
> Can I plot, say a wall, and then subtract away doorways with negative
> objects?
You can make a difference of two objects in order to do that.
Note, however, that the way that CSG works, it may not result in the
most efficient result in terms of rendering speed. (The slowing down
effect is the worse the more holes are made into the big object with
'difference'.)
In the case of a room, it may be more efficient to build a wall using
the union of its parts rather than the difference of one big wall and
smaller objects.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> You can make a difference of two objects in order to do that.
Indeed. My question was, can I "force" a difference to take place _outside_ of
a formal difference{} directive?
For example, _somewhere_ in the SDL is a box{} defining a wall of the structure.
The idea is that I can define a whole room as an addition - including the
doorway - and simply tack on that object {room rotate translate} statement to
the end of the SDL, and the doorway would not only overlap the wall, but "cut" a
hole in it.
I'm not too concerned about render speed at the moment - it would be more for
the purposes of "rapid prototyping" and modular construction that would do away
with the need for extensive editing of pre-existing SDL code.
> ...it may be more efficient to build a wall using
> the union of its parts rather than the difference of one big wall and
> smaller objects.
Interesting. I'll file that datum away for future reference.
Post a reply to this message
|
|
| |
| |
|
|
From: Warp
Subject: Re: ex post facto difference - "negative" objects
Date: 27 Aug 2013 17:33:32
Message: <521d1b2c@news.povray.org>
|
|
|
| |
| |
|
|
Bald Eagle <cre### [at] netscapenet> wrote:
> > You can make a difference of two objects in order to do that.
> Indeed. My question was, can I "force" a difference to take place _outside_ of
> a formal difference{} directive?
I'm not sure what you are asking.
Put your room object and the cutting object inside a difference{}.
What is the problem?
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 27.08.2013 23:19, schrieb Bald Eagle:
>
>> You can make a difference of two objects in order to do that.
>
> Indeed. My question was, can I "force" a difference to take place _outside_ of
> a formal difference{} directive?
>
> For example, _somewhere_ in the SDL is a box{} defining a wall of the structure.
> The idea is that I can define a whole room as an addition - including the
> doorway - and simply tack on that object {room rotate translate} statement to
> the end of the SDL, and the doorway would not only overlap the wall, but "cut" a
> hole in it.
I guess what you want is
union {
difference {
object { room rotate ... translate ... }
box { ... }
}
object { door_and_frame rotate ... translate ... }
}
which is perfectly possible (also note what I did there do add the
actual door and frame).
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Yep. That nailed it.
I hadn't thought about putting the whole scene inside a difference, and then
only the overlapping parts would be subtracted.
Always these little tricks....
I'll try it out on my WIP and let you know how it goes.
Thanks again.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
OK, I rearranged my SDL and moved my romm-generating loop inside the
difference{} directive. No door openings, and ... no rooms?
I'm sure it's a stupid mistake I'm overlooking - I'll keep working on it.
Do you see the error that I can't?
#declare Room = union {
box {<-1*Feet, 0*Feet, 0.5*Feet>, <1*Feet, 7*Feet, 3.5*Feet> material
{White_Wall}}
box {<0*Feet, 0*Feet, 0.5*Feet>, <0.3*Feet, 7*Feet, 3.5*Feet> texture
{Fake_Wood_Vert}}
box { <0, 0, 0> <-20*Feet, -6, 7.6*Feet>} // floor
box { <0, 0, 0> <-20*Feet, 8*Feet, -6>} // Front Wall
box { <0, 0, 7.6*Feet> <-20*Feet, 8*Feet, 7.3*Feet>} // Rear wall
box { <-20.3*Feet, 0, 0> <-20*Feet, 8*Feet, 7.3*Feet>} // Left/Right "outside"
Wall
material {White_Wall}
translate -x*0.8*Feet}
// WALLS AND ROOMS
difference {
union{
box {< 0*Feet, 0, -4.5*Feet>, <-0.8*Feet, 17*Feet, 76*Feet> material
{White_Wall}} // Left Wall
box {<44*Feet, 0, -4.5*Feet>, <44.8*Feet, 17*Feet, 76*Feet> material
{White_Wall}} // Right Wall
}
#declare Room_No = 0;
#while (Room_No <=9 )
object {Room translate z*Room_No*7.6*Feet}
object {Room scale -1 translate <44.8*Feet, 0, 7.3*Feet> translate
z*Room_No*7.6*Feet}
#declare Room_No = Room_No + 1;
#end // end while
}
Post a reply to this message
|
|
| |
| |
|
|
From: Thomas de Groot
Subject: Re: ex post facto difference - "negative" objects
Date: 28 Aug 2013 03:11:13
Message: <521da291$1@news.povray.org>
|
|
|
| |
| |
|
|
On 27-8-2013 23:19, Bald Eagle wrote:
>> ...it may be more efficient to build a wall using
>> the union of its parts rather than the difference of one big wall and
>> smaller objects.
>
> Interesting. I'll file that datum away for future reference.
>
>
See: http://www.econym.demon.co.uk/index.htm
Thomas
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
EXCELLENT!
Thanks for that link - it helps me solve a perforated mesh problem in another
WIP.
Still having problems understanding my current code error (other than some
errors of haste unrelated to the why-I-haz-no-hole? problem).
I like the systematic progression that demonstrates the cumulative effect of
each CSG operation. I've noticed that even if you "put a light source in a
closed box" - that the camera can't even see, it has a significant effect on the
render time, since POV-ray has no way of knowing that those camera-light_source
ray paths don't enter the scene. I wish there were a clever way to fix / solve
/ work-around THAT problem...
"Proximity lights" - that only get rendered when the camera is within a certain
set distance of the light source...
Post a reply to this message
|
|
| |
| |
|
|
From: Christian Froeschlin
Subject: Re: ex post facto difference - "negative" objects
Date: 28 Aug 2013 18:28:40
Message: <521e7998$1@news.povray.org>
|
|
|
| |
| |
|
|
Warp wrote:
> Bald Eagle <cre### [at] netscapenet> wrote:
>> Indeed. My question was, can I "force" a difference to take place _outside_ of
>> a formal difference{} directive?
>
> I'm not sure what you are asking.
Currently, you can "add" an object to an existing scene
simply by writing
object {...}
The object will appear in addition to all objects in the scene.
It will be (partially) visible unless (partially) contained or
covered by other objects.
But you cannot easily "remove" an object as part of the scene
unless you either
- Know in advance which objects will be affected and apply a
difference to them all explicitely
- Restructure your code so all scene geometry is in one giant
union, then you can later difference away anything.
Basically, think of an #include library of architectural
components. You already have house, know you want to add
some windows to it. It would be nice if you could do it
by writing
object {Shuttered_Window translate <to_where_I_need_the_thing>}
and this would not only add the elements of the window but also
"add the hole" that is required for the window. Note that the hole
could affect multiple elements of the existing architecture.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |