POV-Ray : Newsgroups : povray.general : Status of Moray? : Re: New SDL for POVRay Server Time
13 Jul 2025 22:11:22 EDT (-0400)
  Re: New SDL for POVRay  
From: Patrick Elliott
Date: 5 Oct 2007 16:09:42
Message: <MPG.217047eceb841d3098a039@news.povray.org>
In article <4705eeb7$1@news.povray.org>, 
fab### [at] yourshoesskynetbe 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

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