 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
William Tracy wrote:
>
> Quick question for the group:
>
> Does anyone see any value in being able to use OO syntax to
> transform an object *after* it's declaration,
There is some value.
The current SDL way:
#local A = sphere { 0, 1 }
// an instance of A
object { A
translate y*1
rotate z*10
rotate x*20
scale <23,44,33>
}
// another instance of A
object { A
translate y*2
rotate z*10
rotate x*20
scale <23,44,33>
}
Possible 4.0 way:
#local A = sphere {
translate y*1
rotate z*10
rotate x*20
scale <23,44,33>
}
// an instance of a
A.transform[0] = <0,1,0>
object { A }
// another instance of a
A.transform[0] = <0,2,0>
object { A }
Just a shortcut, though this might help with instancing of CSG objects
(makes sense to me that it would. Ask a programmer.). The point isn't
that it's terribly useful for changing the transformation of an object.
The point is that it *is* terribly useful for playing around with huge
lists of mesh vertices AND that the perhaps marginal usefulness of using
it with spheres would cause others to use it in even simple scenes,
making the SDL harder to learn.
To address something Patrick Elliot said: Don't understand media and you
won't understand media scenes. Don't understand a major language concept
and you won't understand many scenes at all.
-Shay
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> How about:
>
> #local MyOb = difference {
> sphere { 0, 1 translate y*2 rotate z*45 translate <2,3,4> }
> object { Some Other Object }
> }
>
> MyOb.subtrahend.transforms[1].addrotate(<0, 0, 15>);
> MyOb.subtrahend.transforms[0] *= <1,0,0,0,0,1,0,0,0,0,0,1,0,5,0,1>
>
> which would end up *everywhere*. And the small minority who do
> understand it would be "responsible" for supporting this feature in the
> newsgroups.
If a small minority creates obfuscated code, it won't end up everywhere,
because it's a... mhhh... minority. Besides, community spirit will
lead many people to take care of writing simple and clear code. Also,
currently, there are already some complicated macros out there,
which few are able to fully understand, you can't always avoid
complexity. Finally, in many situations, re-using someone's code
doesn't imply fully understanding it (I'm not able to understand a
fractal tree macro everyday, but I can use it everytime).
> "I did it without 3rd party apps!" only impresses within this community
> and isn't going to get POV-Ray by for another 15 years. New users, drawn
> by capabilities they can put to use without a comp-sci degree, are what
> will guarantee POV's future.
Doing things without 3rd party apps is not a matter of looking smart.
It's a matter of convenience when it can be done.
Let's stay with the example of subdivision surfaces (or any other
automated process for meshes).
I model something in Wings3D. Then I export it to POV-Ray. Suddenly,
I think, oh, I would need one more subdivision level for my object
to look smooth ! If it's done within POV-Ray, there's just a parameter
to change. If not (as currently), I have to go back to Wings, do the
subdivision, and re-export !
Still skeptic ?
Let's talk about displacement mapping. The thing that can transform
a cylinder into a screw in no time. If it's external, I have to freeze
the model to a certain scale and depth of displacement, and the
resulting mesh will be huge and will take time to read into POV.
If I can do it internally, changing displacement parameters would
be a snap, and much less time will be needed to process (everything
would happen in fast memory).
Many examples of such added flexibility could be found...
Fabien.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> Shay <Sha### [at] cc cc> wrote:
>
>>Best example I've seen yet, and a very compelling, but I'm not sold.
>
>
> Ok, clearly there's no way to convince you,
>
I think that the way to do that is to let him know that he is being
heard. Shay is carrying the torch for a number of us, probably, who
fear that the simplicity of the current SDL may be lost, and fear also
that overambitious goals may lead to naught. Though a bit sarcastic at
times, he has presented some coding cartoons that very accurately
portray our fears. Shay, who personally would be perfectly comfortable
with arcane and cryptic coding patterns, is worried about those who
would not be.
On your side, it seems, you fear you are also shouting into the wind.
That no one more than you loves POV for what it is and only seek to
improve on the thing, and modernize it by some basic organizational
changes. In a very startling way, the one thing that you and Shay seem
to agree on is the need for shaders. I think what you are offering here
is further ways that the shader model could be used to improve the POV
interface. I acknowledge and trust your advanced knowledge of lowlevel
programming and how computers work on the more basic levels. Your
suggestions make common sense to me. You want support for better data
stuctures. That makes common sense to me. If you ideas would allow the
more technically talented to add speed and fuctionality for the less
technical of us to take advantage of,...great. That has always been one
of the backbones of this community.
But I also know that people are subject to the fashion of ideas. As one
person once said to me, 'the great thing about standards is that there
are so many to choose from.' In other words we all fear that the
organization advantage of a comman standard is the need for some
personalities to want to control the behavior of others. And everyone,
naturally, would prefer a set of gestalts that they are the most
comfortable with.
This was crystalized for me in another place by Bruno Cabasson's
illustration of an inheritance scheme. And I have valued Bruno's
contributions to his discussion for their clarity, and also his effort
to illustrate what he means with a syntax example. Because as soon as I
saw it, I understood its appeal,...but not to me.
So I wonder, Warp, if there might be a way that you could more clearly
diagram you ideas such that we could see the advantages and fear less
the idea that we all need to turn into C programmers?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
William Tracy wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Shay wrote:
>> How about:
>>
>> #local MyOb = difference {
>> sphere { 0, 1 translate y*2 rotate z*45 translate <2,3,4> }
>> object { Some Other Object }
>> }
>>
>> MyOb.subtrahend.transforms[1].addrotate(<0, 0, 15>);
>> MyOb.subtrahend.transforms[0] *= <1,0,0,0,0,1,0,0,0,0,0,1,0,5,0,1>
>
> Quick question for the group:
>
> Does anyone see any value in being able to use OO syntax to transform an
> object *after* it's declaration, in the general way shown in Shay's
> example? (I would like to hope that we could come up with a cleaner
> syntax than that.)
Yes. I think if you have a complicated scene where the position of
objects is either random or is changing during an animation, it is
better to have all the instantiations of objects in one place and
everything that positions it close together.
For an animation it could even mean that you can 'precompile' all
objects and don't have to reparse everything, but only reposition the
moving parts. But that might require saving an internal state to disk.
>
> In principle, it seems like it could be useful, but I can't actually
> come up with any concrete examples of things that couldn't be
> accomplished in the current SDL.
>
I can't either.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Quick question for the group:
>
> Does anyone see any value in being able to use OO syntax to transform an
> object *after* it's declaration, in the general way shown in Shay's
> example?
Yes, especially on objects collections. Say you have a set of 100
spheres. Initially, they are small and red. You want 60 of them
to become big, and 60 of them to become blue, but only 10 will
be blue AND big. Either you make a complicated loops system,
either you just apply, successively, new parameters to 2 different
subsets of spheres.
> (I would like to hope that we could come up with a cleaner
> syntax than that.)
(the syntax above is very pessimistic)
> In principle, it seems like it could be useful, but I can't actually
> come up with any concrete examples of things that couldn't be
> accomplished in the current SDL.
Bruno Cabasson's example code looks like a good start to me.
Fabien.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Jim Charter wrote:
> But I also know that people are subject to the fashion of ideas. As one
> person once said to me, 'the great thing about standards is that there
> are so many to choose from.'
I always thought that quote was supposed to be sarcastic. 8-|
--
William Tracy
afi### [at] gmailcom -- wtr### [at] calpolyedu
You know you've been raytracing too long when you can no longer tell the
difference between the top raytracing book and the "Raytracing for
Dummies" book. To you, they're both hopelessly uninformed.
-- Taps a.k.a. Tapio Vocadlo
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFHBoZAcCmTzQ++ZncRAny0AJ9EQ77OcHkpbpjHE0rNf92UNm/9bACgsrES
DWLnviFI/4bLQeCohVBLgkI=
=R9wr
-----END PGP SIGNATURE-----
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Possible 4.0 way:
>
> #local A = sphere {
> translate y*1
> rotate z*10
> rotate x*20
> scale <23,44,33>
> }
>
> // an instance of a
> A.transform[0] = <0,1,0>
> object { A }
>
> // another instance of a
> A.transform[0] = <0,2,0>
> object { A }
>
The real OOP way would be:
Sphere A = sphere {
translate y*1
rotate z*10
rotate x*20
scale <23,44,33>
}
// an instance of a
A.transform[0] = <0,1,0>;
scene.addObject(A);
// another instance of a
A.transform[0] = <0,2,0>
scene.addObject(A);
addObject could also apply to CSG objects :) I think it's nicer to do this:
Union all = union{};
/* shinyThings is an array */
foreach(obj in shinyThings) {
all.addObject(obj);
}
Than using POV-Ray's current "power" to put loops anywhere:
union {
#foreach(obj in shinyThings)
object { obj }
#end
}
This is just like allowing macros anywhere: it blocks from doing many
performance improvements. Evil stuff like this is currently possible:
#declare I=0;
#while (I<10)
union {
#declare I=I+1;
#end
whatever
#declare I=0;
#while (I<10)
}
#declare I=I+1;
#end
Just as bad as #macro abuse.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Bruno Cabasson <bru### [at] alcatelaleniaspacefr> wrote:
> I am digging a solution with Java as an intermediate langage.
Using the Java bytecode as the bytecode used in POV-Ray could be an
idea, but I'm not sure it's the only or the best possible existing
bytecode format and engine.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
William Tracy <wtr### [at] calpolyedu> wrote:
> Does anyone see any value in being able to use OO syntax to transform an
> object *after* it's declaration, in the general way shown in Shay's
> example? (I would like to hope that we could come up with a cleaner
> syntax than that.)
Being able to *read* object data would at least be very useful, for
example to export the scene to some file format.
Modifying the object could be useful at least with meshes. If support
for modifying meshes is added, why limit it there?
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
|
|
