"Chris B" <nom### [at] nomailcom> wrote:
>
> POV-Ray does have some features that make this sort of thing fairly
> straight-forward once you're familiar with the syntax and constructs. I
> wouldn't wish to overstate the ease with which this can be done as it's a
> lot of work, but your post implies that you're looking to invest a fair bit
> of time, so getting a straight-forward standardised approach at the outset
> is probably a good starting point.
>
> One feature that I would consider important is the array syntax which allows
> you to store arrays of objects, text strings, transformations etc. The other
> is the 'transform' syntax which means you can easily store transformations
> and read them back later so that you can accumulate or reverse (inverse)
> them.
>
> With a bit of careful design, you can set up an array to hold the component
> parts of the building, a corresponding array to hold the transformation and
> as many other arrays as you feel you need to index these two main arrays.
> One of the indexing arrays can hold the name of the component, so that, once
> declared, you can use the name of the object to refer to it instead of
> having to remember the indices. This also makes your code more readable.
> You can add other indexing information as you require, for example you could
> add an indicator to show if it's part of the walls, the roof, the floors or
> the furniture (a sort of 'category' classification).
>
> To add a component you would call a macro that increments the array index,
> stores the object, the transformation, the component name and the category
> etc, passed in as parameters. You can create a simple macro to look up any
> previous transformation based upon the component name, so that you can
> position a component relative to any component that's already been declared.
> You can then have a set of macros to draw your chosen image, whether it be a
> 3D perspective image or a 2D plan or section. These macros can decide what
> to include in the image based on the 'category' array, or on any other
> indexing information you choose to implement.

I was playing around with an idea like this a week or so ago. I was trying to
build some high level abstraction that would let me construct "objects" with
arbitrary properties, so I could then write macros that dealt with those
objects, rather than lower level POV data.

This is what I got to (it's all a bit unfinished, but the basic work):

/ * Create an "object" with 5 slots. Returns a ref you can use to reference
    the object later (it's an int) */
#local ref = Property_CreateObject( "StudioSoftBox", 5 ); // name, num fields

/* Prints out just the object name, and the fact it has 5 empty slots */
Property_PrintObject( ref )

/* Add some properties to the object */
Property_SetString( ref, "name", "Left Softbox" )
Property_SetString( ref, "description", "A softbox, already, already" )
Property_SetColor( ref, "color", rgb <1,0,0> )
Property_SetVector( ref, "location", <500,2000,300> )

/* Now prints out the object with it's 4 filled in slots */
Property_PrintObject( ref )

/* Get one of the properties by name */
#declare the_name = Property_Get( ref, "name" );
#debug concat( "name = ", the_name, "\n" )


> Regards,
> Chris B.

Cheers,
Edouard.

Post a reply to this message

"Edouard" <pov### [at] edouardinfo> wrote in message 
news:web.4ab71754ba1022f62feef4220@news.povray.org...
> "Chris B" <nom### [at] nomailcom> wrote:
>>
>> POV-Ray does have some features that make this sort of thing fairly
>> straight-forward once you're familiar with the syntax and constructs....
>
> I was playing around with an idea like this a week or so ago. I was trying 
> to
> build some high level abstraction that would let me construct "objects" 
> with
> arbitrary properties, so I could then write macros that dealt with those
> objects, rather than lower level POV data.
>

I guess what I said does lead in that sort of direction, but I have gone in 
that sort of direction in the past and fallen foul of a few problems and I'd 
propose something a bit lighter.

I think there's a danger of designing a programming layer on top of the SDL 
(a sort of framework) which may solve certain problems, but which can make 
things more complicated in the end. When you come to try and share that with 
others they need to learn that framework in addition to the POV-Ray SDL, 
which I think is often too much like hard work for most people. Also there's 
a risk that people are constrained and can only do what the framework was 
designed to do (a sort of keyhole programming).

A lot of people probably want to combine elements from different sources, 
e.g. a terrain generator, a modeller and hand-coded or macro generated CSG 
objects. Constraints added as a sort of layer on top of the SDL tend to 
limit people to tools that are compatible with one paticular framework 
approach.  So, having slept on it I think I'd advocate stepping back a bit 
from that edge.

Taking the problem of relative coordinate placement in isolation for a 
moment, I believe it's possible to follow a more 'lite' approach as 
illustrated in the following examble. It's a fully functioning example, so 
you can play around with it. It just declares some transformations that can 
be used to position objects, texutres, cameras, lights, etc. relative to 
other objects. POV-Ray lets you accumulate transformations, so you can 
readily define a House datum relative to the plot of land it sits on, a 
Bathroom datum relative to the House datum and a datum for the shelf to hold 
your toothbrush relative to the Bathroom datum.

You can then add your toothbrush to the shelf without going through the 
mental trauma of calculating its position relative to a fencepost in the 
garden. Of course you still need to get your brain around the relative 
positions when you're declaring or adjusting these datums, but it should 
reduce the mental effort when working on component parts.

If you subsequently need to reorient the whole plot of land relative to the 
street that it's on (and you've used this technique reasonably consistently 
to position things), you can simply add a new datum representing the 
lamppost at the end of the street and changing the Garden datum to inherit 
it's position and orientation from that. You can even have datums whose 
positions are controlled by the clock, for example on a train passing the 
end of the garden.


// Position the plot of land relative to the origin
#declare Garden_Datum = transform {
  rotate y*25
  translate <-2,0,-5>
}
// Position the house relative to the land
#declare House_Datum = transform {
  translate <2,0,5>
  transform {Garden_Datum}
}
// Position the bathroom relative to the house
#declare Bathroom_Datum = transform {
  translate <1,2.4,2.5>
  transform {House_Datum}
}
// Position the greenhouse relative to the garden
#declare Greenhouse_Datum = transform {
  rotate y*40 translate <2.5,0,4>
  transform {Garden_Datum}
}

camera {location <0,1.5,0> look_at <0.5,1.5,1> transform {Garden_Datum}}
//camera {location <0,1.5,0> look_at <0.5,1.5,1> transform 
{Greenhouse_Datum}}
light_source {<1,50,-100> color rgb 1}

// Create a bath and move it into
// the corner of the bathroom
box {<0,0,0><0.6,0.4,1.6>
  pigment {agate}
  transform{Bathroom_Datum}
}

// Build a Greenhouse
box {<0,0,0><2,2,2.5>
  pigment {rgbt <0.6,1,0.7,0.6>}
  transform{Greenhouse_Datum}
}

// Position a plant pot relative to the corner of the greenhouse
cylinder {<0,0,0>,<0,0.3,0>,0.1
  pigment {rgb <1,0,0>}
  // Move the plant pot (relative to the greenhouse datum)
  translate <0.2,1,1.2>
  transform {Greenhouse_Datum}
}




Regards,
Chris B.

Post a reply to this message

"Kene" <nomail@nomail> wrote in message 
news:web.4ab710eeba1022f6772dd76f0@news.povray.org...
> "Chris B" <nom### [at] nomailcom> wrote:
>> "Kene" <nomail@nomail> wrote
>> > I am building a set of macros and hopefully functions that can assist 
>> > an
>> > architect in making a building using POVRay.
>> ...
>> > My hitch right now is that I cannot enable relative coordinate 
>> > placement.
>> >
>> > It is important to be able to create an object relative to the position 
>> > of
>> > another in architecture.
>>
>>
>> POV-Ray does have some features that make this sort of thing fairly
>> straight-forward once you're familiar with the syntax and constructs....
>>
>
> This is great! Exactly what I was looking for. It sounds like worth the 
> effort
> because I wanted to stay with the SDL as much as possible. I will 
> investigate
> this instead of creating a new program for now. I am also interested in 
> your
> method for floor plans.
>
> ... I think that design is so
> much more fun when you can type... Its just like
> having a conversation if you know what I mean.
>

Yes, I too get some sort of odd pleasure from being able to just describe 
something that the computer can draw.

I have been thinking about this problem of relative positioning for a long 
time and each time I come back to it the answer seems to get simpler and 
simpler. After posting last night I set about experimenting further and I 
came up with something that (at present) feels like the simplest possible 
approach. So much so that it's hard to imagine why it didn't seem obvious to 
me before. I've described it in my response to Edouard and provided a 
trivial but complete functioning example.

One important difference between this approach and last-nights posting is 
that it means that the datums are not necessarily bound to each and every 
component of the building. It would certainly be possible to create a datum 
for each component, but it would also be possible to deviate from that, 
where appropriate. For example, you could create the building fabric (walls, 
columns, doors and windows) relative to a single 'building' datum, then 
build out an auditorium on the third floor using a datum at the centre of 
the stage, whereas a kitchen could be constructed relative to the corner of 
the room, making it easier to align furniture with the walls.

I think this is probably very close to the way most people work anyway, 
defining a discrete object relative to the origin before orienting and 
moving it to its final position. The only behavioural change is therefore to 
use the name of the predefined transformation to do this, so that a sort of 
hierarchical transformation structure can be slotted into the scene file. 
This approach avoids introducing an extra macro layer that might potentially 
interfere with using objects generated using modellers, macros or utilities 
as you should still generally be able to take the complete object, wrap it 
in an object or a union statement and apply the appropriate transformation.

Regards,
Chris B.

Post a reply to this message

Hi:

I am really excited about this. If I had known during my Ph.D. research I would
have used POVRay instead of creating a prototype that I have to discard.

I am itching to implement my ideas but let me take some time and explain what I
am doing. The discussion that is going on so far and some old discussion on
POVRay arrays in 2003 by Jaap Frank is really throwing a lot of light and ideas
at me.

I am actually trying to implement a Building Information Modeling System using
POVRay. The overview of my thesis is that buildings are composed of parametric
objects and so we should not focus on drawing lines or even creating objects but
on design and analysis. We should set custom parameters (what you referred to as
Datum, I think) such as "Site_Datum = Location", "Building Level 1 = 4500 mm",
"Building Level 1 Wall Height = 3000 mm", "Stair Riser = 150 mm", "Building
Level 1 Wall Insulation = R4", etc. Basically all the minimum requirements from
the user and from the architectural standards will be known by the software as a
way to assist the designer. This is just a part of the requirements that you
will supply to the tool. Some will be coded into macros that the user does not
see but some the user should be able to change.

Then the basic objects that will be used are Spaces, Walls, Windows, Doors, etc.
The designer starts with spaces. It is easy to put spaces to sort out your
circulation and proximities. These will have default parameters so that the
designer does not have to type a lot in the beginning. These defaults can also
be change if there is a desire. For example with a few strokes of the key a user
can create spaces of different shapes and sizes (right now only rectilinear,
circular and trapezoid) with tinted transparency. This is because these spaces
are created with Envelops at all sides. Door and Window openings can be added to
the Envelopes with a few additional commands to show functionality in the
design.

Once the spaces seem to make some sense, detailed Walls with different finishes
and treatments (preferably real world options from Sweets catalogue or the
firm's preferred door and window schedules) can be replaced for each part of the
Space object with a few modifying commands to the spaces.

To simplify this for architects (a lot of whom do not like typing, I must say) I
use macros to do a lot of the work. The user just enters the relative
dimensions, treatments and types of objects. I have set up this framework and to
me it is fun so far. I need to move things into macros like I have described but
the following is a little on my implementation so far.

For example:
- First of all I included arrays.inc so I can redefine my arrays without
destroying what is saved inside
- I have an array called Wall_Props. This is the only array that holds
everything about the walls.
- When creating a wall the user needs to include an identifier, preferably
whatever the declared name is. This string is initialized to an integer for
example:
BedRmWall01Coords = 1
BedRmWall01Texture = 2
- An array to hold the Wall Coordinates and another to hold the Texture, etc.
- Then I connect them in a single array with the following
#declare Wall_Props[BedRmWall01Coords] = Wall_Coords
#declare Wall_Props[BedRmWall01Texture] = Wall_Texture

The user then makes a wall with
#declare bedRmNorthWall = object{ Make_Rect_Wall( "bedRmNorthWall", "bedroom
wall on the north side", 5000, 3000, 230 )}

In the macro Make_Rect_Wall, the Wall_Props is resized and the necessary
information is added.

This wall is then placed in the scene by the designer by using a Put_Wall
command with relative coordinates. A macro gets the coordinates for the wall
using the supplied id to access the current coordinates (which is initially set
at the origin by Make_Rect_Wall. Then the wall becomes visible.

I may be rambling here but I have not had much sleep. I need to prep for work
but looking forward to this weekend. the main point for me though is that now I
can really have fun with building and actually begin to create and manage
building information the way it should be without the influence of the
commercial CAD vendors. Eventually, it should be possible (I can actually taste
it already) to export the building information using a format like STEP of IFCs.
Then any software out there can read it and give me flat plans and section.

Post a reply to this message

Chris B wrote:
> Well I'm glad you pointed that out, I hadn't noticed that geocities was 
> going.
> 
> Regards,
> Chris B.

There are *lots* of POV-Ray related pages hosted on GeoCities. I'm 
afraid they will all disappear as well.

:(

-Mike

Post a reply to this message

"SharkD" <mik### [at] gmailcom> wrote in message 
news:4ab7ab8d$1@news.povray.org...
> Chris B wrote:
>> Well I'm glad you pointed that out, I hadn't noticed that geocities was 
>> going.
>>
>> Regards,
>> Chris B.
>
> There are *lots* of POV-Ray related pages hosted on GeoCities. I'm afraid 
> they will all disappear as well.
>
> :(
>
> -Mike

Maybe it's worth a thread on povray.general to try and prompt people to move 
their POV-Ray stuff across to alternative sites while there's still time.

I did a Google, restricting the domain for the search to geocities.com and 
it came back with 540 results, some of which are the same author. It might 
be possible to organise a little community project to make attempts to 
contact authors to save some of that. We'd need to be a little organised to 
avoid spamming authors. Some sites may also give explicit permission for 
someone else to copy the content. I'll see if I can get a list off in 
machine readable format.

Last night I copied POV-House onto freewebsites.com, which was a relatively 
painless process: http://povhouse.freewebsites.com/
I still need to go through and update some links and the free web hosting 
sites don't seem to support zip files anymore (or .pov or .inc extensions), 
so I put the downloadable files onto MediaFire and linked them into the new 
freewebsites.com page.
It only took a couple of hours to do and I plan to do the same with my other 
geocities POV sites.

It might be an opportune time to see whether previous generations of macro 
and include file authors would be willing for their work to be loaded onto 
the POV-Ray Object Collection instead of them having to bother with their 
old web sites.

Regards,
Chris B.

Post a reply to this message