POV-Ray : Newsgroups : povray.advanced-users : Enabling relative coordinate placement : Re: Enabling relative coordinate placement Server Time
3 Jul 2024 04:57:37 EDT (-0400)
  Re: Enabling relative coordinate placement  
From: Edouard
Date: 21 Sep 2009 02:05:00
Message: <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
> 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

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.