"architype" <arc### [at] gmxcom> wrote:

> Those look pretty good! :)

Thanks - I think that took about 3 months, and it could look a lot better.

> Btw I took a look at the pov-ray docs and it turns out you can add "normal on"
> in the radiosity statement and get normals to work.

Read the docs, eh?
'round here we call that _cheating_   ;)
Next thing we know, you'll be reading the source code....

> What would you like to do btw,

I think I'd like to help work out some of the planning / workflow / code
aspects, and work on a building or feature or three to give me something
specific as a goal.


> And since all my .inc files have a default camera that can be
> accessed
> by setting the debug switch to 1 it should be workable.
> It just needs a little
> documentation so you know which file is the main scene.

I generally use a .pov file for the main scene, and use .inc or .mcr files for
defining specific complex objects or writing larger macros that are best left
out of the main scene file for clarity.
I don't use a manual switch so much as I let the scene determine automatically
if it's a sub-portion or standalone.
I define a variable called SDL, and then in the .inc file, I check if it's
defined.  If it is, then the include file is being called as an .inc, if it's
not, then I'm working on the .inc file and I want to render it as a standalone
scene, so I invoke all of the usual camera, lightsource, skysphere stuff in the
#else section.


> Unfortunately there is no overall idea, just the primitive urge to model... ;-)
> [s]and voices in my head telling me what to do...[/s]

A kindred spirit, I see.   ;)


> As for windows, I normally dont spend that much time on them and usually only
> make a simple frame and perhaps some glass.

I was just asking, since it's often hard to "go back" and add a window when
you're making modular constructs, or a window in one segment can be covered by
another...


> Yes the idea is to do a modular architectural toolkit eventually, but it is
> such a big undertaking so right now I will make use of what I got and just do
> some design of the rustic library and implement just enough to get the first
> scene done.


I hear what you're saying, and there is definite logic and value to producing a
_fait accompli_ as proof of concept.

I need to look at Chris Colefax's city macro to see what he does to make very
large numbers of random buildings at a distance.

> Also design can be very tricky, as I have learned the hard way... first there
> is the balance between ease of use and control over details.
> Second between the features you want and the features that are easy/possible to
> implement...
> Third there is ease of implementation contra writing code that is efficient to
> use/runs fast.
> When it comes to meshes it means keeping the numbers down and removing those
> that do not belong/overlap/are not visible.

I've been looking at "frustrum clipping" here:
http://paulbourke.net/miscellaneous/povexamples/
and need to work out what's going on so that I can do things like determine
what's in the camera view, etc.   Then eliminating nonessential objects can be
automated to some extent.
It would also be great to write an .pov file for new users so that they can SEE
how changing camera values has an effect on the scene, and see the interplay
between right, up, angle, etc.


> One quick and dirty hack I have in mind is placing houses, ie write a box
> component
> and then arrange them neatly. Convert to pov and replace the box component with
> a
> detailed pov component. That would be neat if it worked.

Sound like it ought to work splendidly.


> But I need to put some more thought into design first. For example it might be
> necessary to have 2 parameters for level of detail; one for modelling and one
> for texture. (Ie you might want to skip the trees when testing, but maybe the
> full detail texture needs to be shown, ie with normal etc)
> And should the component only pass its parameter on to the sub components?
> (It might not be that easy, for at some level, small components should
> probably not be drawn at all. Showing also that there should be an LOD = -1

I think a lot of that can be handled in a "control panel" at the top of the main
scene.   Just wrap certain scene items in an #if #end block, and select or
deselect them.   There are also POV-Ray's render Quality levels that can be
invoked.

Work stuff like that in early on, and it makes it a lot easier to incorporate it
into the code / workflow and be thinking that extra step or two ahead when
coding a scene.


P.S.
I have just managed to make some mesh spheres starting from either an octahedron
or an icosahedron - still a few small bugs I need to work out, and then maybe
that might be of use for certain scene elements.

Post a reply to this message