|
 |
In article <4705eeb7$1@news.povray.org>,
fab### [at] yourshoes skynet be says...
>
> > new Sphere s;
> > s.Position=[1,1,10];
> > s.Radius=.7;
> > s.Texture.Pigment=[0,1,0];
> > s.Scale(1,2,1);
> > s.Rotate(30,0,0);
> >
> > That is all very clear coding, but *not* what most of the group here
> > wants. POV4 should be easy to understand in it's most basic declarative
> > form. Which in my opinion means that objects as virtual representations
> > of things visible in your scene will have a different status and
> > different syntax than all other 'objects'. Borrowing standard OOP
> > language may be rather confusing in that respect.
>
> Sure, there's something to find to avoid that kind of cumbersome syntax.
>
> I don't tkink anyone around here would like to make an object's definitio
n
> so complicated. There should be some kind of shortcuts, looking like
> current SDL.
>
> Fabien.
>
What we need is something "between" the extremes. Something that allows
you to look at the sub-levels of an object in the parts of the SDL that
handle execution and looping, etc., which still keeping the "creation"
of the object reasonably distinct.
Lets put it another way. In stuff like VB and others you can do
something like:
typedef fred
jim as integer
nosh as string * 2
endtype
dim gg as fred
Then when you *used* that, you gain the ability to do:
gg.jim = 5
Same thing here, in theory. The initial creation of an object doesn't
need to fundamentally change at all, just how the "code" level of the
SDL "sees" the object once it exists. The only possible issue I can see
is with a few things like rotate/scale, etc., where you might need to
use an enumeration to keep track of which one you are working with. But
that's not a huge problem. Lets say you have:
#declare body = object {... arm{rotate blah 'some other stuff' rotate
blah2} ...}}
And you want to adjust the "first" rotation.
body.arm.rotate(0)="<5,0,0>"
Wow! So hard... And the *initial* creation of the object didn't change
on tiny bit, its still standard SDL, you just now have more control over
each individual aspect of *that* object. And its not likely to be that
complicated to tell the difference between 'body.arm.rotate(0)
="<5,0,0>"' and say 'body.arm.texture(0).rotate(0)="<5,0,0>"', right?
Please, some one explain to me why this is supposed to be a horrible
idea, or requires some silly, "new object s;", BS to do anything. At
worst it wouldn't make sense to use it to do anything but make copies of
existing objects, at best, its redundant for even that, since its much
easier to use another declare to produce a new name for it. Point being,
some thought may been to go into how to handle multiple objects in
enumerations/arrays, such as when generating them through a trace, so
that you have the same level of access to specific objects. Such as
liking the position of 49 of 50 trees that get "planted" by it, but
needing to make some minor change to the 50th. You could do that "in"
the trace loop, or you could do it "after", by just referencing that
specific tree in an array. Both would work, but in some cases the later
"might" be more useful, if for no other reason than clearly setting the
statement that makes the change some place other than in your loop, you
could make it more "visible" to someone looking for such adjustments.
Puting the code to make minor adjustments in the middle of the same mess
that generates what you are adjusting could obfuscate "both" the changes
and the code doing the generation, if you have to make a number of such
changes.
And yeah, I know, there are bound to be lots of examples of how you
could do it some other way. Ok, here is something, for this example. You
have something that you want, in an animation, to zip back and forth
between "random" trees in your trace. You do a) keep a list of the
locations for every tree, so you can pick random ones from "that", or
keep an array of the trees, so all you need to do is look at the
location of tree 14, 3, 7, then 12, etc., from the trees themselves?
Again, you could do it either way, but one of those is going to a) slow
the parse a bit more, and b) take more memory to store redundant
information.
Anyway...
--
void main () {
call functional_code()
else
call crash_windows();
}
<A HREF='http://www.daz3d.com/index.php?refid=16130551'>Get 3D Models,
3D Content, and 3D Software at DAZ3D!</A>
Post a reply to this message
|
 |