 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Just have a look at the fragment of code I put in the "Attempt to POV4
> Syntax basics" thread I just started.
I've seen it. Very interesting, I like that. Waiting for the fire :-)
(be very cautious when speaking of Java, some people will interpret it
as "he wants to write POV scenes in Java", or "he wants to rewrite
POV-Ray in Java"...)
Fabien.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Fa3ien <fab### [at] yourshoes skynetbe> wrote:
>
> > Just have a look at the fragment of code I put in the "Attempt to POV4
> > Syntax basics" thread I just started.
>
> I've seen it. Very interesting, I like that. Waiting for the fire :-)
>
> (be very cautious when speaking of Java, some people will interpret it
> as "he wants to write POV scenes in Java", or "he wants to rewrite
> POV-Ray in Java"...)
>
> Fabien.
I know. But I am ABSOLUTELY NOT thinking of a rewrite in Java, nor do I want
to write scenes in java. On the contrary, I am digging a bit about how the
new syntax might look like, while keeping what is nice in the current
notation.
I am digging a solution with Java as an intermediate langage. I try to find
how we can take advantage of the characteristics of Java (linguistic,
syntax, runtime, ...) for POV4. So far, this solution permits high-level
features that pov lacks today. It also permits an easy translation from
POV4 to Java. Then the Java compiler makes the low-level job.
Thats a start point, but now, we have to think effectively of the syntax
itself and find a match between feature and notation.
As I said earlier, the syntax is one thing, how to parse/compile POV4 code
is another, and the last but not least, the rendring engine in another big
concern.
I'll try to suggest some more fragments of code. Help welcome.
But I did not dig enough yet to say it is a dead end. Help welcome also.
Would you participate to this investigation? Who would?
Bruno
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Fa3ien wrote:
>
>> All basic flow-chart type stuff. Understood clearly by even
>> non-programmers. Objects?
>
> Would it be difficult to understand that a sphere is an object,
> with properties (position, size, texture...) and methods
> (translate, rotate, copy,...) ?
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.
> Well, a powerful SDL would also allow easier implementation of
> advanced techniques such as hair.
It would, and I believe the SDL should have sufficient power to do so.
Enough power for render-time subdivision surfaces? No. "Extra" data
structures and methods for modeling algorithms and text-processing? No.
"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.
-Shay
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
-----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.)
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.
Anyone?
- --
William Tracy
afi### [at] gmailcom -- wtr### [at] calpolyedu
You know you've been raytracing too long when you spend more time
"tweaking" a texture than modelling the rest of the scene.
-- Twyst
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFHBmjhcCmTzQ++ZncRAitFAJ9dcfk7dBH57x1ARKlBqTq1EqhPpACgnUwq
ZGs6Do9ExvIWpdGoIFISCkU=
=0LZV
-----END PGP SIGNATURE-----
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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] cccc> 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
|
|
| |
| |
|
|
|
|
| |
|
|
