 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp a écrit :
> 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, so we can stop trying.
> You have expressed your opinion at it has become clear. Case closed.
The goal of this discussion, IMO, is not to convince someone that
someone else is right, it's to draw a picture of what can be ahead,
including the pros and the cons of any proposal.
His worries are perfectly licit and likely represent those of many
people. This should be adressed with enough distanciation.
Fabien.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Fa3ien <fab### [at] yourshoesskynetbe> wrote:
> Warp a écrit :
> > 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, so we can stop trying.
> > You have expressed your opinion at it has become clear. Case closed.
>
> The goal of this discussion, IMO, is not to convince someone that
> someone else is right, it's to draw a picture of what can be ahead,
> including the pros and the cons of any proposal.
>
> His worries are perfectly licit and likely represent those of many
> people. This should be adressed with enough distanciation.
>
> Fabien.
I don't really see that this kind of support is a key point in POV 4, but I
also don't see how it could be a bad thing. I suspect the people spending
time implementing these libraries in SDL' aren't going to be the same
people writing the core code, or rather they don't have to be.
On the mesh issue, render-time subdivision would be interesting, although
for me textures usually seem to outweigh meshes in storage requirements,
and (again for me) minimising render time is more important than memory
use. Render-time subdivision is nice for the first use case, and I would
hope it wouldn't adversely affect the other. I can't see myself making much
use of more general mesh manipulation capabilities in POV, but I can't see
the negative impact, really. From the description it sounds like they would
be a "there-if-you-need-them" feature.
Other things I wanted to mention:
* There seems to be a lot more talk about the future SDL than any future
rendering capabilities.
* Specifically on programmable shaders, how will we maintain backwards
compatibility to the somewhat bitty and odd features like irid? Built-in
shader "library"?
* Probably been mentioned before, but I can't remember; will POV 4.0
incorporate any code at all from 3.7, or will it be a complete rewrite?
* I love media {}. Most of the jobs it fails at are actually jobs for an
improved shading language, in my view. For many things it's excellent, even
compared to some professional applications, unusually.
Tom
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Fa3ien <fab### [at] yourshoesskynetbe> wrote:
> His worries are perfectly licit and likely represent those of many
> people. This should be adressed with enough distanciation.
His worries may be valid, but his proposed solution is not.
He has got it completely backwards. The new scripting language is going
to make the core code *simpler*, not more complicated (because tons of
features currently in the core code can be removed from there and moved
to libraries). Also there's nothing in a more powerful scripting language
that will automatically make it harder for the average user to use. In
fact, it could well be the opposite: If well designed, the new scripting
language could be *easier* to use than the current SDL (or at least make
many things a lot easier).
With a powerful scripting language lots of features of the core code
can be removed from there, making the core code smaller and simpler, and
it will then be easier to add features to the core code which really need
to be there (if they can't be implemented in the scripting language or it
would be too inefficient to do so).
Also a well-designed scripting language will make it much easier to
offer an easy-to-use interface to the core features. In the current SDL
each time a new feature is added, adding the correspondent SDL construct
is usually a pain, makes the parser more complicated and overall has a lot
of overhead.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Shay wrote:
> Warp wrote:
>> Shay <Sha### [at] cccc> wrote:
>>> C) Invent and code a new programming language and then code the
>>> algorithm in that language.
>>
>> Right, because all that is necessary for every single algorithm which
>> will be ever made for POV-Ray.
>>
>
> Not quite. I suppose one set of commands would take care of a handful of
> converters. The mesh-handling stuff? Well there's decimation for
> marching cubes of isosurfaces or CSG. Subdivision? Of what? Who creates
> mesh models without a mouse (except me)?
>
I do (sometimes)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
nemesis wrote:
> andrel <a_l### [at] hotmailcom> wrote:
>> As you might have noticed, not everybody is convinced we should have one (SDL).
>
> hello?! Drop povray's SDL and povray is just among many rendering engines.
> I believe to be the crown jewel of povray!
So do I. "one" did not refer to "SDL", as you are apparently assuming,
but to "new SDL".
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
St. wrote:
[snip]
> As it happens, from a non-programmers point of
> view, I think this thread has been a frenzy of what everyone *wants*,
What I get from the thread so far is that:
- syntax of the declarative part (objects, textures, transformations,
...) should stay the same.
- the control structures with # (#if, #macro, ...) should stay (at least
for now)
- there should be a new set of control structures. Especially to replace
the #declare and #macro. This should be closer to a conventional
programming language
- it should be possible to create new objects with the same syntax as
current ones (box, sphere, etc.)
- More of the internals should be exposed. The representation of e.g. a
mesh should be known and modifiable at user level to create a
subdivision, to convert an isosurface of the fly into a mesh, to write
new import routines, etc.
- At many points it should be possible to call user functions in stead
of predefined choices. And those functions should be able to call many
internal functions. This is needed for new shaders and such.
- binary input and output should be supported from within new style
functions.
> and in the end, I think nothing will happen directly resulting from
> this thread imo.
I expect all of these things to be in POV4.
Anyone dare to answer the question on whether POV4 should be a scene
description language or a scriptable ray tracer?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
andrel <a_l### [at] hotmailcom> wrote:
> - binary input and output should be supported from within new style
> functions.
This also needs new efficient data containers and methods for handling
them (so that it can, for example, be parsed and interpreted easily and
efficiently).
> Anyone dare to answer the question on whether POV4 should be a scene
> description language or a scriptable ray tracer?
Both?
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> andrel <a_l### [at] hotmailcom> wrote:
>
>> Anyone dare to answer the question on whether POV4 should be a scene
>> description language or a scriptable ray tracer?
>
> Both?
>
Does that mean that a camera will be optional?
Can the sole purpose of a POV4 script be to create a scene and then
output it in some format like STL (for a 3D printer)?
Will the camera be just one of the functions that gets a scene as input
to produce some output or will it be handled in a special way?
Will scan-line rendering( or filling a pipeline of a graphics card) of a
scene be another option in order to get a fast rough idea of the
composition?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Fa3ien wrote:
> Shay a écrit :
>
>> But how many people are we excluding by obfuscating the SDL?
>
> its both possible to have a simple SDL, accessible even to
> beginners, and to have new extended programming possibilities.
> (and 90% backward compatibility, too). That should be
> verified by producing theorical SDL code for simple situations.
Looking forward to that process. I hope what how the SDL *will* be used
will be taken into account, not just how it *can* be used. One could
write very clear Perl or c++, but the languages aren't necessarily used
that way in practice. I'm as guilty as anyone else. I know maybe 10% of
Python, but a lot of what I know is the ugly stuff. My Python code would
be no more instructive to a beginner than that of any advanced Python
guru. Almost anyone could understand my POV code.
>
> POV-Ray's current SDL is already a programming language. There
> are
> loops,
Repeat an instruction several times
> conditional,
Do something if a condition is met
> and functional macros.
Repeat an instruction several times
All basic flow-chart type stuff. Understood clearly by even
non-programmers. Objects?
> there's much more than meshes in a POV-Ray scene. If CSG could
> be instanciated, and if we had more programming power (and speed)
> within SDL, we could make images of unprecedented complexity,
> images that couldn't be done with any other app, while not
> requiring extreme skills.
Will these images entice savvy 3D users into exploring POV-Ray? I've
used POV's scripting and instancing to produce "images that 'couldn't'
be done with any other app." Here, where 90% of images take a couple
night's work, mine impress. On CG Talk, they'd be torn apart for bad
lighting.
The road to "higher" is clearly paved. You could render 10 million CSG
models, and no CSG-Talk member would be sold on POV-Ray. Create a great
skin or hair texture and you'll have 'em coming.
>
> If you look at Gilles Tran's images, you will see that, except for
> pre-made people, cars, and such, everything is done in SDL.
Yes, he used it as it has been intended, to script his scene, not to
model it.
-Shay
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <47052101$1@news.povray.org>, Sha### [at] cccc says...
> Fa3ien wrote:
> >
> > Imagine you have a mesh which requires subdivision, and are
> > making an animation. If POV-Ray performs the subdivision,
> > various instances of the mesh could be subdivised at different
> > levels, according the distance from the camera
>
> Best example I've seen yet, and a very compelling, but I'm not sold.
> This simplification would require more than just distance to the camera,
> angle of incidence would also have to be considered. The system would
> need to be fairly complex to produce a decent result, and characters,
> landscape, and teapots would all require different rules. One person
> might someday do this if the SDL were extended enough.
>
> But how many people are we excluding by obfuscating the SDL?
>
> When much of the code in p.text.s-f looks like this:
> MacroName (*Param1, %Param2%$, ....)
> new users will not be willing to commit to learning POV's (among free
> renderers) "Killer App" (scripting interface).
>
> "Scripting" may mean something different to programmers. but it means
> something particular to me - something distinct from "Programming." I
> think POV is best served by a "Scripting Interface."
>
> I've said several times that if it's necessary for shaders, it needs to
> be included. Modeling *will* be done 99% with outside apps, no matter
> what is included in the SDL. A lot lost for very little gained IMO. If a
> non-user read this thread, he might conclude that there are scores of
> people hand-coding complex scenes in POV or MEL[1], just champing at the
> bit waiting for the ability to make even more complex scenes this way -
> this is NOT the case.
>
> -Shay
>
Lets be clear about two things. 1) I don't one bit like the idea of
using external apps to do anything, if I can avoid it, simply because
instead of improving Moray to the point where it does most of those,
(and that is *part* of the issue here), you get 50 different ones, each
of which does one things well, then 100 others that do all those things
poorly, and frankly... unless you are being paid by fracking ILM, you
are *not* going to be able to afford all that crap. That is why I would
rather see a lot of it *in* POVRay, and what isn't, in Moray. So the
number of ones you *have to have* that are not going to work 100% with
it anyway, is 1-2, not 20-30.
2) The point of using a decent script language, instead of just cramming
more stuff into the existing one, is that you can make real libraries,
that can have clear descriptions for what they do, and how to use them,
*not* so that everything is MacroName(blah, blah...), which breaks half
the time because one loop some place is flaky, or something, and it
didn't generate a valid object. SDL as it stands *will* generate that
kind of insane mess. I would think fixing it, so you could code real
functions into it, or even going as far as, I don't know, providing some
way to include help file info into an include, so that if you want to
know how something works, the guy that made the functions can have their
own help on that item auto-linked into the existing help (at least as a
search term). Something like a few special tags, which the parser
otherwise ignores, except that, once included, it adds to the help file.
Or, better yet, if someone loads a new include for the first time, that
info gets stored in a DB of the added features, along with specifics,
like what include it belongs to, etc. Sort of, (forgive me, I know some
people hate XML):
<include_meta>
Library_name="mylib"
<help>
additem="myfunction"
description="..."
additem="blah"
...
</help>
</include_meta>
If its already there, its ignored, if it needs to be updated, it is, if
it isn't in the help, it gets added to the search list, then loaded when
requested through that. (Though I have no idea if Windows would support
doing that.)
Point is, the problem with such stuff isn't that a) its not possible to
design explainable functions (though the existing Media feature could be
a good example of something that new people are not going to get
*despite* being described, based on the existing help. lol), or b) using
a more flexible language would make it worse. The real problem is that
we have techies writing stuff for other techies, just like lots of other
stuff in the OSS community (and SDL more or less qualifies as OSS, of a
sort), instead of thinking about what its going to look like when
someone that has *no* clue which end it even up in the the program tries
to use it for something.
Your complaint is mute. There are already things in it *right now* that
fall into the category of, "How the hell does this actually work?", for
a new user. Arguing that this is going to happen "after" you change the
SDL is rather odd. lol
--
void main () {
If Schrödingers_cat is alive
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Shay a écrit :
> 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,...) ?
Concepts like classes might be harder, but we won't really know
until sample code is produced.
> Will these images entice savvy 3D users into exploring POV-Ray? I've
> used POV's scripting and instancing to produce "images that 'couldn't'
> be done with any other app." Here, where 90% of images take a couple
> night's work, mine impress. On CG Talk, they'd be torn apart for bad
> lighting.
>
> The road to "higher" is clearly paved. You could render 10 million CSG
> models, and no CSG-Talk member would be sold on POV-Ray. Create a great
> skin or hair texture and you'll have 'em coming.
In the commercial apps, world, it's often a matter of fashion. Some
years ago, radiosity was most fashionable, now it's faces and skin.
Well, a powerful SDL would also allow easier implementation of advanced
techniques such as hair. I talked about CSG as an example, but every
aspect of POV-Ray would benefit from
>> If you look at Gilles Tran's images, you will see that, except for
>> pre-made people, cars, and such, everything is done in SDL.
>
> Yes, he used it as it has been intended, to script his scene, not to
> model it.
Look at this :
http://www.oyonale.com/variations/variations.php?name=v0207.jpg&lan=fr
Fabien.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Fa3ien wrote:
> Shay a écrit :
>
>> 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,...) ?
>
No, but it could be to a problem to understand that your internet socket
isn't an object in the same sense. You can create a unifying mechanism,
often known as OOP or similar, but you then have to code the sphere
something like
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.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
andrel a écrit :
> 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 definition
so complicated. There should be some kind of shortcuts, looking like
current SDL.
Fabien.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Fa3ien <fab### [at] yourshoesskynetbe> wrote:
> andrel a écrit :
>
> > 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 definition
> so complicated. There should be some kind of shortcuts, looking like
> current SDL.
>
> Fabien.
In my scheme, this code would rather be the Java generated intermediate
code.
Bruno
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Bruno Cabasson a écrit :
>
> In my scheme, this code would rather be the Java generated intermediate
> code.
I had missed your post with sample code. I tend to like what it looks like.
Personally, I am not against something entirely new. I seldom reuse POV code,
anyway, and more flexibility is so attracting.
However, IMO, there's gonna be a huge shields-up from the community, unless
some concerns are properly adressed :
- usability : being able, for example, to define a sphere (position, radius, texture
and
transforms) in a single line is a must. Efficient shortcuts should be possible.
- compatibility : being able to use existing code, or continue coding in classic SDL
style. Maybe in some kind of wrapper, like :
LegacySDL
{
union {
sphere {<0,0,0>,2}
box {...}
}
}
Trying to avoid these issues will lead to an endless mess of hot discussions, I think.
Fabien.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Fa3ien <fab### [at] yourshoesskynetbe> wrote:
> Bruno Cabasson a écrit :
> >
> > In my scheme, this code would rather be the Java generated intermediate
> > code.
>
> I had missed your post with sample code. I tend to like what it looks like.
>
> Personally, I am not against something entirely new. I seldom reuse POV code,
> anyway, and more flexibility is so attracting.
>
> However, IMO, there's gonna be a huge shields-up from the community, unless
> some concerns are properly adressed :
>
> - usability : being able, for example, to define a sphere (position, radius, texture
and
> transforms) in a single line is a must. Efficient shortcuts should be possible.
> - compatibility : being able to use existing code, or continue coding in classic SDL
> style. Maybe in some kind of wrapper, like :
>
> LegacySDL
> {
> union {
> sphere {<0,0,0>,2}
> box {...}
> }
> }
>
> Trying to avoid these issues will lead to an endless mess of hot discussions, I
think.
>
> Fabien.
Just have a look at the fragment of code I put in the "Attempt to POV4
Syntax basics" thread I just started.
Bruno
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Bruno Cabasson a écrit :
> 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] yourshoesskynetbe> wrote:
> Bruno Cabasson a écrit :
>
> > 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:
> Shay a écrit :
>
>> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Shay a écrit :
> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
William Tracy a écrit :
> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Shay escribió:
> 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...
> andrel a écrit :
>
> > 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 () {
If Schrödingers_cat is alive
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Patrick Elliott escribió:
> 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?
>
I don't know why somebody would need to change individual
transformations. In addition, it could be cumbersome to refer to
transformations by their numerical index Just to let you know: POV-Ray
(currently) doesn't keep individual transformation statements. Every
transformation you do changes the transform matrix of the object, so you
can only do further transformations on the existing matrix. Only way to
edit a previous transform would be to "undo" all that followed, re-do
the changed transform with new parameters, and re-do all that followed.
Also, how would you handle this?
sphere {
<1,2,3>, 0.5
translate <12,35,61>
texture { some_complex_texture }
translate y*2
}
The first translate doesn't affect the texture, the second does.
I think we would be fine with body.arm.rotate(5,0,0) which affects the
current transformation matrix just like current POV does, without having
to keep every individual change that has been done.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Fa3ien <fab### [at] yourshoesskynetbe> wrote:
> 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 !
I think your vertex displacement example makes more sense. It's pretty
obvious in Wings (or any other tool where you have interactive realtime
preview capabilities) how smooth a mesh is (or isn't) after a subdivision.
The main advantage of render-time subdivision is reduced use of disk space
and less parsing.
To provide a counter-example, how about mesh decimation? It's easy to
imagine a mesh where the decimation works well on one part of the mesh but
doesn't do so well in a section of it. It could take many re-renders in POV
(involving a complete adjust-parse-render cycle, nothing like realtime)
before I find parameters for which the decimated mesh looks good. This is
already enough of a pain with renderer-specific features it can't really be
avoided for, like radiosity. When I have access to tools with realtime
preview capability for meshes, it makes much less sense to involve POV for
many mesh operations, in my view.
Making waves on the surface of a mesh ocean during an animation? Thumbs up
to this idea. For *all* mesh manipulation, given the external tool's much
faster preview, POV's attachment to triangles rather than quads, and the
fact that once it goes in to SDL (even future SDL) it's never coming out
again? I don't see the advantage.
Tom
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp <war### [at] tagpovrayorg> wrote:
> 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
For sure. But it is the one that came to my mind. It is just a vague scheme
and general principle. Whatever solution we choose, there will be a quite
long way from the idea to the first 'official' benchmark scene in POV4
syntax. For now,I must cook it a little more and make a more elaborate
example.
BTW, I am quite a good chef, and concerning (french) cuisine, I have good
intuitions and I like to improvise. I never use recipes, I reinvent all the
time, but often use good ol' principles that match the human taste. I also
often search for new ways ...
I'll try to add more POV ingredients into the pans. I remind you that a
dinner has success also because of the quality of the guests. And there are
quality people around here!
Bon appétit, mes amis!
Bruno
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nicolas Alvarez <nic### [at] gmailisthebestcom> wrote:
> Also, how would you handle this?
> sphere {
> <1,2,3>, 0.5
> translate <12,35,61>
> texture { some_complex_texture }
> translate y*2
> }
> The first translate doesn't affect the texture, the second does.
>
Just like POV does (correct me if I am wrong): when translate is encountered
it translates the whole object. At the time of first translate, no texture
is specified yet (=null, I suppose). At the time of the second the sphere's
'texture' field is non-null, thus transformed with the object. The final
state is that de texture has been translated twice.
In new SDL, it would be the same: the translate() method (or whatever it
will be) of an object (or its derived) will apply on whatever there is
inside the current object. You could have also written
sphere {
<1,2,3>, 0.5
translate <12,35,61>
texture { some_complex_texture translate 100*x}
translate y*2
}
with 3 translations for the texture.
Bruno
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Bruno Cabasson" <bru### [at] alcatelaleniaspacefr> wrote:
> In my scheme, this code would rather be the Java generated intermediate
> code.
In my Scheme, this code would be sweet. ;)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Fa3ien <fab### [at] yourshoesskynetbe> wrote:
> Personally, I am not against something entirely new. I seldom reuse POV code,
> anyway, and more flexibility is so attracting.
People with huge custom libraries would certainly disagree.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
William Tracy <wtr### [at] calpolyedu> wrote:
> 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.)
This is something I'd always like to do:
// a 3-legged 1-unit sized stool at origin.
#local stool = Stool { 0, 3 texture { textures.oak rotate 30 } }
stool.scale( .3, 1.4, .3 );
stool.place_on( floor );
stool.away( 3, nw_wall );
#local sph = sphere { 0, 1 pigment { rgb x } }
sph.place_on( stool );
Relative positioning of objects in the scene should benefit imensely from
not having to explicitely keep track of their positions by means of local
variables or half-assed positioning macros. I've placed a sphere upon a
stool on the floor, without ever having to pass their sizes or positions.
Yes, there's trace and some positioning macros that allow us to do something
like that today in the "half-assed" routines we have in our personal
toolsets, but that's nothing compared to having current position and
transform state inside the objects themselves as properties, rather than
needing to declare variables for that purpose.
For instance, the stool is inittially at the origin and then I place it on
the floor, which might be anywhere in the y scale. If I had a macro to
determine the actual position of an object, given the identifier stool, all
it would get would be 0, the original location.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
andrel wrote in message <470### [at] hotmailcom>:
> 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.
This code is a little bit verbose, but not much. Consider the current SDL
equivalent:
#declare s = sphere {
<1,1,10>, .7
texture { pigment { rgb <0,1,0> } }
scale <1,2,1>
rotate <30,0,0>
}
Roughly the same number of lines and characters, and the same
self-documented readability.
I think that "most of the group here" wants the second only because they
already have the habit of knowing it, not because it has inherent qualities.
Which is a point to take into consideration, of course.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Fa3ien wrote in message <47068487$1@news.povray.org>:
> 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.
Then you have to link POV-Ray 4 with libmath-2, because with the current
version, you get 110 objects :-Þ
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>... POV's attachment to triangles rather than quads, and the
> fact that once it goes in to SDL (even future SDL) it's never coming out
> again? I don't see the advantage.
No doubt NURBs will end up in 4.0 in some fashion since
they are requested quite often.
I would think that the syntax of 4.0 must retain most of
the look and feel of current SDL. This is part of why I
think that breaking up the scenes into sections like
environment{} pre_process{} ... scene ... post_process{}
would make sense. That way certain advanced features
would be easily located.
Imagine being able to overload object definitions...
environment {
overload {
box{A,B}
//wireframe objects
cylinder {A,<A.x,A.y,B.z>,0.05} ... etc
}
}
in order to change all the regular boxes in your scene into
wireframe. This is aspect oriented, which is a good fit
for Pov, IMO.
Object oriented would mean the attachment of methods...
for non-programmers that means functions, which in the
case of Pov probably would end up being to manipulate
graphic objects. That might end up with something like...
box {A,B
modify {wireframe(diameter)}
}
Where wireframe is a method for box. The problem with
this is that wireframe is probably going to be defined
somewhere in C++ instead of in SDL. The functions would
be handy, but limited by your ability to program and
compile, most artists will avoid that I think.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Bruno Cabasson escribió:
> Nicolas Alvarez <nic### [at] gmailisthebestcom> wrote:
>
>> Also, how would you handle this?
>> sphere {
>> <1,2,3>, 0.5
>> translate <12,35,61>
>> texture { some_complex_texture }
>> translate y*2
>> }
>> The first translate doesn't affect the texture, the second does.
>>
>
> Just like POV does (correct me if I am wrong): when translate is encountered
> it translates the whole object. At the time of first translate, no texture
> is specified yet (=null, I suppose). At the time of the second the sphere's
> 'texture' field is non-null, thus transformed with the object. The final
> state is that de texture has been translated twice.
>
> In new SDL, it would be the same: the translate() method (or whatever it
> will be) of an object (or its derived) will apply on whatever there is
> inside the current object. You could have also written
>
> sphere {
> <1,2,3>, 0.5
> translate <12,35,61>
> texture { some_complex_texture translate 100*x}
> translate y*2
> }
>
> with 3 translations for the texture.
>
> Bruno
>
>
You missed my point (because I didn't make it so clear :P). How would
you handle that *and* allow syntax like this?
sphere.translate[0]="<5,0,0>"
I think it's a bad idea to allow changing individual transformation
statements after the object has been created.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nicolas Alvarez <nic### [at] gmailisthebestcom> wrote:
> sphere.translate[0]="<5,0,0>"
> I think it's a bad idea to allow changing individual transformation
> statements after the object has been created.
There's no such a thing as a "translate" element in a sphere (or in
any other object for that matter). Thus it would make no sense to have
such an element in the sphere object of the new SDL either.
What should exist is a *function* (member or not) which applies the
translation to the sphere (which is a different thing). Calling this
function will, naturally apply the subsequent translations properly
(as well as other transformations).
(In general all transformations are internally collected into a
4x4 transformation matrix, except when the transformation can be
optimized away by eg. transforming the center point of the sphere
only. However, there exists no "translate" member variable in the
sphere object or any other object.)
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nicolas Alvarez wrote:
>>
> You missed my point (because I didn't make it so clear :P). How would
> you handle that *and* allow syntax like this?
>
> sphere.translate[0]="<5,0,0>"
>
> I think it's a bad idea to allow changing individual transformation
> statements after the object has been created.
why? In the current SDL objects can still be moved after creation. They
can not after rendering begins, but you have a point, if a shader has
access to all underlying data structures, it could move any object while
rendering. That would break any attempt to subdivide the task over
processors. We need to make sure that all properties are locked during
rendering. Or are there properties that could be changed?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nicolas Alvarez <nic### [at] gmailisthebestcom> wrote:
> Bruno Cabasson escribió:
> > Nicolas Alvarez <nic### [at] gmailisthebestcom> wrote:
> >
> >> Also, how would you handle this?
> >> sphere {
> >> <1,2,3>, 0.5
> >> translate <12,35,61>
> >> texture { some_complex_texture }
> >> translate y*2
> >> }
> >> The first translate doesn't affect the texture, the second does.
> >>
> >
> > Just like POV does (correct me if I am wrong): when translate is encountered
> > it translates the whole object. At the time of first translate, no texture
> > is specified yet (=null, I suppose). At the time of the second the sphere's
> > 'texture' field is non-null, thus transformed with the object. The final
> > state is that de texture has been translated twice.
> >
> > In new SDL, it would be the same: the translate() method (or whatever it
> > will be) of an object (or its derived) will apply on whatever there is
> > inside the current object. You could have also written
> >
> > sphere {
> > <1,2,3>, 0.5
> > translate <12,35,61>
> > texture { some_complex_texture translate 100*x}
> > translate y*2
> > }
> >
> > with 3 translations for the texture.
> >
> > Bruno
> >
> >
> You missed my point (because I didn't make it so clear :P). How would
> you handle that *and* allow syntax like this?
>
> sphere.translate[0]="<5,0,0>"
>
> I think it's a bad idea to allow changing individual transformation
> statements after the object has been created.
Maybe it's me who did not understand well ;o)
However, my vision of things is that the MyObjectType { } block could be a
notational/convenience shortcut, as close to current syntax as possible (at
least obeing the same notational principles), for a 'constructor' in the
sense of 'creating a new object of a specific king with specific
characteristics you valuate'.
What we could decided right now by people here, is: would it be possible to
change charateristics of an object AFTER its creation, displacing it,
changing its texture, or performing specific operations (some basic
mesh-editng ...?)?
We caould have something like:
YES --> Form 1:
my_stool = Stool
{
<stool class properties, that were not defaulted in class definition>
< or overridden properties>
}
..../...
my_stool.to_mesh();
my_stool.some_mesh_editing_feature();
my_stool.smooth(); // It's a mesh now
NO --> Form 2:
my_stool = Stool
{
<stool class properties, that were not defaulted in class definition>
< or overridden properties>
to_mesh();
// It's a mesh now, so, it inhertits mesh methods
some_mesh_editing_feature();
smooth();
}
The second form would allow method calls within the creation block, and the
syntax would be more likely not to allow any further modification outside
this block(= after creation). Thinking of that while typing these lines, I
prefer Form 2.
Remark: a new syntax (or whatsoever) cannot be mature at first try. We will
have to make several rounds before the new syntax is considered as
'usable'. My experience is that nothing is really OK before version 3.
Version 1 is a first attempt to have 'all together', version 2 often
implies changes in the approach and many modifications corrections making
the system 'work', version 3 is the one that makes 'all together' AND
'working' AND 'quite fine'.
Bruno
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Bruno Cabasson <bru### [at] alcatelaleniaspacefr> wrote:
> What we could decided right now by people here, is: would it be possible to
> change charateristics of an object AFTER its creation, displacing it,
> changing its texture, or performing specific operations (some basic
> mesh-editng ...?)?
I don't see why not.
This is *especially* true with transformations, given that transforming
an object is an operation done to the object (which is collected into a
single transformation matrix), not a property of the object.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp escribió:
> Nicolas Alvarez <nic### [at] gmailisthebestcom> wrote:
>> sphere.translate[0]="<5,0,0>"
>
>> I think it's a bad idea to allow changing individual transformation
>> statements after the object has been created.
>
> There's no such a thing as a "translate" element in a sphere (or in
> any other object for that matter). Thus it would make no sense to have
> such an element in the sphere object of the new SDL either.
>
> What should exist is a *function* (member or not) which applies the
> translation to the sphere (which is a different thing). Calling this
> function will, naturally apply the subsequent translations properly
> (as well as other transformations).
>
> (In general all transformations are internally collected into a
> 4x4 transformation matrix, except when the transformation can be
> optimized away by eg. transforming the center point of the sphere
> only. However, there exists no "translate" member variable in the
> sphere object or any other object.)
>
Yep, that was my point. Transforming the object further should *of
course* be allowed (complex CSG would become fairly impossible without
that!), but having all individual transformation "items" stored in an
array and being modifiable seems like a bad idea.
That was what Patrick Elliot said, and I was replying to:
> And you want to adjust the "first" rotation.
>
> body.arm.rotate(0)="<5,0,0>"
>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
andrel escribió:
> Nicolas Alvarez wrote:
>
>>>
>> You missed my point (because I didn't make it so clear :P). How would
>> you handle that *and* allow syntax like this?
>>
>> sphere.translate[0]="<5,0,0>"
>>
>> I think it's a bad idea to allow changing individual transformation
>> statements after the object has been created.
>
> why? In the current SDL objects can still be moved after creation. They
> can not after rendering begins, but you have a point, if a shader has
> access to all underlying data structures, it could move any object while
> rendering. That would break any attempt to subdivide the task over
> processors. We need to make sure that all properties are locked during
> rendering. Or are there properties that could be changed?
One thing is moving an object after creation. Another is "changing a
previously-defined translate" (that's not currently possible in SDL, and
it's a bad idea anyway). See my reply to Warp.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nicolas Alvarez wrote:
> Warp escribió:
>> Nicolas Alvarez <nic### [at] gmailisthebestcom> wrote:
>>> sphere.translate[0]="<5,0,0>"
>>
>>> I think it's a bad idea to allow changing individual transformation
>>> statements after the object has been created.
>>
>> There's no such a thing as a "translate" element in a sphere (or in
>> any other object for that matter). Thus it would make no sense to have
>> such an element in the sphere object of the new SDL either.
>>
>> What should exist is a *function* (member or not) which applies the
>> translation to the sphere (which is a different thing). Calling this
>> function will, naturally apply the subsequent translations properly
>> (as well as other transformations).
>>
>> (In general all transformations are internally collected into a
>> 4x4 transformation matrix, except when the transformation can be
>> optimized away by eg. transforming the center point of the sphere
>> only. However, there exists no "translate" member variable in the
>> sphere object or any other object.)
>>
>
> Yep, that was my point. Transforming the object further should *of
> course* be allowed (complex CSG would become fairly impossible without
> that!), but having all individual transformation "items" stored in an
> array and being modifiable seems like a bad idea.
>
> That was what Patrick Elliot said, and I was replying to:
> > And you want to adjust the "first" rotation.
> >
> > body.arm.rotate(0)="<5,0,0>"
> >
As warp said, at the moment the individual transformations are not
stored and there is absolutely no reason in POV4 to do so.
And even if there would be an array of transformations, the textures
(which is your main problem, I think) would get there own array and
would not get influenced by such after the fact changes.
BTW in POV there is indeed an interaction of transformations and
textures that comes from the fact that our textures are 3-dimensional.
I have not much experience with other 3D software but it may be one of
the things that set POV apart from others. I think that in the context
of POV4 we should think about how 3D textures influence our scenes and
how they influence our programming language.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nicolas Alvarez <nic### [at] gmailisthebestcom> wrote:
> Another is "changing a
> previously-defined translate" (that's not currently possible in SDL, and
> it's a bad idea anyway).
Somehow I feel you are a bit talking about apples and oranges here.
Of course there's no way of "changing a previously defined translate"
because there's no such thing as a "previously defined translate". As I
said in the other post, a translation is not a property of the object,
it's an operation applied to the object (in other words, in object-oriented
terms, a translation is not a member variable of the object, it's a member
function). You either apply it (so that it has some effect) or you don't.
You can't go "back in time" and apply it in a different way once you have
applied it already.
(Technically speaking you can later apply a new set of transformations
which cancel out the earlier translation, so the effect is the same as if
the earlier translation had not been performed at all, but this is a
rather different thing at a basic conceptual level.)
I can't really see what is the problem people are seeing here. I don't
see any problem in objects in the new SDL having transformation functions
which work in the same way as in the current SDL.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp escribió:
> Nicolas Alvarez <nic### [at] gmailisthebestcom> wrote:
>> Another is "changing a
>> previously-defined translate" (that's not currently possible in SDL, and
>> it's a bad idea anyway).
>
> Somehow I feel you are a bit talking about apples and oranges here.
>
> Of course there's no way of "changing a previously defined translate"
> because there's no such thing as a "previously defined translate". As I
> said in the other post, a translation is not a property of the object,
> it's an operation applied to the object (in other words, in object-oriented
> terms, a translation is not a member variable of the object, it's a member
> function). You either apply it (so that it has some effect) or you don't.
> You can't go "back in time" and apply it in a different way once you have
> applied it already.
>
> (Technically speaking you can later apply a new set of transformations
> which cancel out the earlier translation, so the effect is the same as if
> the earlier translation had not been performed at all, but this is a
> rather different thing at a basic conceptual level.)
>
> I can't really see what is the problem people are seeing here. I don't
> see any problem in objects in the new SDL having transformation functions
> which work in the same way as in the current SDL.
>
I was just commenting on Patrick's examples which showed changing
individual transformations, stored in some sort of array. So we are
agreeing. The way transformations should work is the way they currently do.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
