> > Those look pretty good! :)
>
> Thanks - I think that took about 3 months, and it could look a lot better.
>

I can imagine that. I also find that I run out of time to make a better
scene, really use the models to their full potential.

> > 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....
>

Yeah software is supposed to be intuitive and the good stuff is. And I often
tend to do without the manual. That or I stop using it. :p
But povray really needs some explanaition of course, since the subject is a
little complex...

> > 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.
>

So, a little of everything, just like me. :)


> > 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.
>

Interesting. The reason I can do without an SDL variable is that all my stuff
is created at <0,0,0> and that I have some parameters for the camera, ie
location and look at.
About the .pov file; I really should do it your way, but often testing of the
main .inc file degenerates into creating the final scene... ;)
But there is also a point with making everything an .inc because there are so
many files and so many layers of folders.
(The base lib has 1000+ files and more than 6 layers of folders; ie a scene has
multiple buildings, a building has multiple components, each component has
several elements, each element is broken into moulds and those in turn into the
basic shapes like cylinder and box...)


>
> > 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.   ;)
>

Absolutely. :)
>
> > 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...
>

That is probably true, even though I havent had that particular problem yet.
The trouble for me has been version control and having to update lots of #macro
calls when I wanted to add more parameters.

>
> > 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.

That sounds interesting.

>
> > 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.
>

Frustrum clipping seem interesting.
Yes, I really should follow the .pov standard.

>
> > 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.
>

I will test and report.

>
> > 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.

Hmmmm I am not sure it is that simpe given the structure of my code, I have
sometimes made an .inc file with global variables but that is a messy approach.

>
> 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.
>

That is solid advice.

>
> 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.

That should be very useful, I saw your other threads.

Best wishes, /A

Post a reply to this message