 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Chris Cason wrote:
> andrel wrote:
>> Can someone set something up somewhere?
>
> Can someone recommend specific Wiki software?
>
> It'd need to support external authentication (to link in to the POV user
> registration system), and captchas or other anti-spam measures.
Mediawiki seems a natural choice because a lot of people know how to use
it (from wikipedia) and anything we need in the lines of the above is
probably already available in some form. For authentication a long list
of extensions can be found on:
http://www.mediawiki.org/wiki/Category:User_identity_extensions
Christoph
--
Views of the Earth: http://earth.imagico.de/
Images, include files, tutorials: http://www.imagico.de/
MegaPOV with mechanics simulation: http://megapov.inetart.net/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
>
> * Existing data containers, namely arrays and strings (which are special
> arrays of characters), should be enhanced and new data containers introduced.
> For example the current array could be internally implemented as a C++ deque,
> which would make it work like the current one plus you can freely resize it
> (larger or smaller), append elements at the beginning and at the end, and
> you can still access any element fast, and none of these operations will be
> slow (eg. resizing does not require copying/moving any existing elements).
> Even inserting or removing elements from the middle of the array would be
> possible, although it would not be a constant-time operation.
The Asymptote array concept provides a fairly flexible sort of array:
http://asymptote.sourceforge.net/doc/Arrays.html
The internal representation is derived from deque i think.
Christoph
--
Views of the Earth: http://earth.imagico.de/
Images, include files, tutorials: http://www.imagico.de/
MegaPOV with mechanics simulation: http://megapov.inetart.net/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Bruno Cabasson a écrit :
> Is it still ray-tracing? You only get an image that is based on a ray-traced
> one. But if you end up with what you want, then OK.
It's not raytracing, indeed, it's post-processing. The post-processing
included in megapov (for example) isn't raytracing, either. The purpose of
post-processing is precisely to allow some transformations over the already
rendered image, ideally using more data (like depth or normals) than the image
itself, but it happens AFTER rendering, which makes it fast and flexible.
If we are discussing render-time effects, well, okay, but let's not call it
POST-processing, then. Just call it 'effects' (and limit them to things
that *cannot* be done in post-processing).
Nevertheless, simultaneous output of rendered image, and depth, normal,... data
would allow extremely interesting things to be done (besides being easy to
implement).
(BTW, thinking of it, being able to simultaneously output images with different
settings would be great; i.e : rendering an image with and without media,
but doing intersection calculations only once; of course, it becomes
complicated...)
Fabien.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp a écrit :
> Fa3ien <fab### [at] yourshoes skynetbe> wrote:
>> How, in the system you envision, will I be able to change the
>> focal point and get a new image within a few seconds, instead
>> of taking 3 hours to re-render everything ?
>
> Regardless of which method is used it's clear that povray must keep
> all the necessary information in files (or at the very least in memory)
> between renders.
>
> There could be a few possibilities:
>
> 1) An option to tell POV-Ray to write all the necessary information on files.
> Then if you want to re-post-process, you just use the option +C to skip
> the rendering.
> One disadvantage of this is that you have to remember to use the option
> if you want to be able to post-process multiple times.
If POV-Ray "sees" there's a file with post-process data, it can ask the
user if he really wants to re-render or not. Also, an "archival" mode (POV-Ray
gives an automatically numbered name to its output) would avoid any
dangerous overwrite (and allow to easily keep a record of an image's evolution,
which is currently tedious).
> 2) POV-Ray could always write the extra info on files, allowing
> post-processing whenever you want.
> The disadvantage is that it will consume disk space and the user would
> have to manually delete those unneeded files to clean it up.
Disk space is cheap in these days of hard-disks filled with music and videos.
> 3) POV-Ray could automatically write the info on files and keep them there
> as long a it's running, and when it's closed, it removes them (unless
> an option is given). This would allow re-post-processing the image as
> many times as necessary as long as POV-Ray is running.
> The disadvantage is that this idea doesn't work with the command-line
> version. Another slight disadvantage is that if the execution of the
> program is ended abruptly, the files will be left there.
>
> 4) As 3, but the info is kept in memory until next render.
> Doesn't garbage the disk, but has the same disadvantages.
>
> Make your pick, or suggest something better.
All in all, I think that there could be a choice (for the user) between :
1) write to files, keep it forever (default)
2) write to files, keep it until session ends
I think that "keep in memory" would quickly lead to memory saturation (fast
memory is precious for rendering).
Option 2 would be unavailiable to command-line, but there could be a script
to clean unused files afterwards. Maybe the files (in option 2) could be
written in some temporary path.
Fabien.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Bruno Cabasson wrote:
>
> Right.
>
> But the concern is so present that the question of a new SDL is 'on air'
> since quite a while, made this discussion happen, and interests a lot of
> people (I think). And I bet that those people you mentionned, once/if ever
> POV has its new nice syntax with new long-awaited features, will be the
> first to use it with greed ... The demand for new POV-SDL araised from the
> lacks and drawbacks of POV, even if it is a marvelous tool.
>
> Bruno
:)
I guess you would call me one of "those people".
Don't get me wrong, I'm not against a new language perse but I am against "a
new language for the sake of a new language". If at the end of the
discussion it turns out that the current SDL cannot be cleaned up/extended
to do what we all want it to do, then off course we need a new language.
But implementing a new language has major cons.
1) All current and older projects are useless because of loss of backwards
compatibility.
2) We'll upset/drive away a good portion of the current userbase because of
the new syntax.
--
Ger
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Fa3ien escribió:
> If POV-Ray "sees" there's a file with post-process data, it can ask the
> user if he really wants to re-render or not. Also, an "archival" mode
> (POV-Ray
> gives an automatically numbered name to its output) would avoid any
> dangerous overwrite (and allow to easily keep a record of an image's
> evolution,
> which is currently tedious).
That's just a GUI detail. Well, you *better* aren't thinking on adding
"ask the user" to the rendering backend...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nicolas Alvarez a écrit :
> Fa3ien escribió:
>> If POV-Ray "sees" there's a file with post-process data, it can ask the
>> user if he really wants to re-render or not. Also, an "archival" mode
>> (POV-Ray
>> gives an automatically numbered name to its output) would avoid any
>> dangerous overwrite (and allow to easily keep a record of an image's
>> evolution,
>> which is currently tedious).
>
> That's just a GUI detail. Well, you *better* aren't thinking on adding
> "ask the user" to the rendering backend...
That would logically be done at front-end (CLI or GUI) level.
Fabien.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Fa3ien <fab### [at] yourshoesskynetbe> wrote:
> Disk space is cheap in these days of hard-disks filled with music and videos.
Not when rendering animations.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp a écrit :
> Fa3ien <fab### [at] yourshoesskynetbe> wrote:
>> Disk space is cheap in these days of hard-disks filled with music and videos.
>
> Not when rendering animations.
Well, let's give the option to not keep the files, then.
(hope some wiki or dedicated group will come soon, this thread
is becoming huge !)
Fabien.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ger <No.### [at] ThankYou> wrote:
> I guess you would call me one of "those people".
> Don't get me wrong, I'm not against a new language perse but I am against "a
> new language for the sake of a new language". If at the end of the
> discussion it turns out that the current SDL cannot be cleaned up/extended
> to do what we all want it to do, then off course we need a new language.
> But implementing a new language has major cons.
> 1) All current and older projects are useless because of loss of backwards
> compatibility.
> 2) We'll upset/drive away a good portion of the current userbase because of
> the new syntax.
>
> --
> Ger
That's not so obvious to me. AFAIK, compatibility problems already happened
in POV's life when the syntax evolved and new features were added. The
#version clause was added for that. If the new syntax inherits enough from
the current one, we can imagine either that the new is a subset of the old
and the new parser will understand old syntax, or converters can be
developped (which is not far from the first case). I can't imagine that the
new syntax makes less features than the old, so I dont't see why there would
be an impossibility.
However, the arrival of a new syntax is a major change, thus we can't hope
making a significant step without some eventual concessions.
Even if lots of nice stuff was produced with pov 3.6 & megapov 1.2.1 syntax,
it appears that many people feel limited and want something new. That's the
reason of this discussion and justifies we think seriously about it and try
to determine the WHAT, the WHY, and the HOW.
Bruno
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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)?
This will all sound a lot better after someone has taken care of the
many things that POV users cannot do (rendering algorithms). After that,
what POV users cannot *conveniently* do might seem a lot more important.
-Shay
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Shay <Sha### [at] cccc> wrote:
> 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 really don't understand your attitude. You are mocking the few
examples given (and even quite illogically at that) and you refuse to
see the big picture behind those examples.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <470313c2@news.povray.org>,
nic### [at] gmailisthebestcom says...
> Patrick Elliott escribió:
> > In article <47024d79$1@news.povray.org>,
> > nic### [at] gmailisthebestcom says...
> >> Umm... Isn't that how things work on *any* loosely-typed language?
> >>
> >> var arr = [123, [12,34], "foo", /\s+public ?(.*)/g, new Sphere(1,2,3
)];
> >>
> >> A valid Javascript array containing a number, another array, a string,
a
> >> regular expression, and a Sphere (provided that the Sphere object was
> >> defined).
> >>
> > Well, all I know is that it wasn't, for what ever reason, possible with
> > the client. That *may* be due to the fact that Java is *not* normally
> > that loosely typed, or that some serious problem existed in ActiveScrip
t
> > which seriously fracked it (since it relies a lot of that for every
> > language except Lua. Though, mind you, half the ActiveScript languages
> > seem to not follow spec anyway and suffer from bloody silly
> > inconsistencies even in how you instance them, never mind get them to d
o
> > anything after they are linked.)
> >
>
> You're mixing up Java and Javascript (they have nothing to do, name
> similarity is apparently because of marketing reasons). Java is
> strongly-typed, Javascript is loosely-typed. Java is compiled into
> bytecode, Javascript is interpreted. Java has classes, Javascript has
> prototype-based OOP instead.
>
I realize there are differences between them, didn't know that was one
of them though. I still don't like the syntax that well. My point was
though that you get the same issues trying to use something like Python.
It didn't link the same way, even though it should have, and worse,
there actually seems to be some sort of insane memory leak in it,
triggered when you drop in some temp code to run, then try to remove it
again. We are not sure if its garbage collection not handling the
deleted code correctly or what, but its frustrating.
Oh, and using Java may not be useful precisely *because* it relies on
compiled Bytecode. Why? Because I am not sure how well it can handle
shifting code in/out on the fly, and while I am not sure how/if that
would be useful in POVRay, since it kind of assumes you are going to
render one frame, then exit, it is a nice things to have some times.
Like say you have a flag to turn off a certain feature, while testing
colors, because it slows things down. So, you figure, "Ok, color is
good, so lets just type in "myflag = 1", so the next frame will render
"with" the feature turned on, so I can see it that is working too,
without having to restart the entire render." Sure, its not the sort of
thing you "expect" to be doing in a program like this, but it can be
useful some times to have immediate execution of a comment "into" the
code that is already running, in some cases. You can't do that with
compiled code.
Now, whether there is a legitimate reason to allow such a thing in
POVRay is another question entirely, as well as how that would effect
speed. But it is something that might be considered. Its also used in
the client I use to do things like reacting to some event, then
inserting code to do some specific task "at that event". Probably not
useful or necessary for POVRay, since coding that in directly, then re-
running the script, is probable just as easy, but again, its something
that could be done real time, even as processing is being done, in the
client I use, while a compiled language simply wouldn't support it.
Useful for something like POVRay or completely useless? Not sure myself.
I am sure I could think of uses for it "if" I had the option, but
thinking of them now is a bit harder.
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Warp" <war### [at] tagpovrayorg> wrote in message
news:4703e3e6@news.povray.org...
> Shay <Sha### [at] cccc> wrote:
>> 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 really don't understand your attitude. You are mocking the few
> examples given (and even quite illogically at that) and you refuse to
> see the big picture behind those examples.
Erm... calm down Warp. I've read every post here and Shay has offered
no less than anyone else. As it happens, from a non-programmers point of
view, I think this thread has been a frenzy of what everyone *wants*, and in
the end, I think nothing will happen directly resulting from this thread
imo.
It's a shame really, because the skill is here, in our very own
community.
(But, I'll be happy to download the 'new' version when it's ready).
~Steve~
> - Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 03.10.2007 20:35, Shay nous fit lire :
> Subdivision? Of what? Who creates
> mesh models without a mouse (except me)?
>
Well, as you ask, me! I transform some solid object in mesh, then
deform them in pov. (personnal edition, of course...)
> This will all sound a lot better after someone has taken care of the
> many things that POV users cannot do (rendering algorithms). After that,
> what POV users cannot *conveniently* do might seem a lot more important.
I'm afraid of a chicken-egg issue in this sterile discussion about SDL.
A full clean-up of the data model would be needed first (far away
from the SDL, at the lowest memory level). Once the future data
model is stable (and beautiful ?), we could look at any rendering
algorithm to see if it fit the actual data or require an extension
(or a bigger evolution). That's something that cannot be done "on
the wind", you need a practical algorithm. Documenting the
data-model could save the trouble for the future generation.
Then, with a reliable data-model, you can have any loony designs its
own SDL to fill that data (or explore it, too). You can even
anticipate a serialisation of the actual data, for easier
saving/loading (including distributed rendering). And again, the
serialisation can be done in whatever loony's designed syntax (XML,
ASN.1 (BER or PER or whatever), bytecode, ...) they want it.
The purpose of parsing is to generate the data for the rendering
engine, everything else are just commodities for the users.
--
The superior man understands what is right;
the inferior man understands what will sell.
-- Confucius
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
St. <dot### [at] dotcom> wrote:
> As it happens, from a non-programmers point of
> view, I think this thread has been a frenzy of what everyone *wants*
No, it's not about what everyone wants, it's about what POV-Ray needs.
POV-Ray needs to improve, else it will slowly fade into oblivion.
The SMP support in POV-Ray 3.7 bought it time, which is really great,
but I'm afraid that will not be enough in the long run. The SMP support
is a huge card for POV-Ray, but it just needs more if it wants to survive
another 15 years.
One thing which POV-Ray needs is more rendering features which would
bring it back in par with other renderers.
While many such rendering features must be added to the core code
because there's no other option, there are, however, a whole lot of
features which can and should be implemented by scripting. These can
often be implemented as surface shaders and such.
Implementing them with scripting has tons of advantages. The features
become more flexible, easily modifiable (without having to recompile
the entire program) and extensible. POV-Ray should move from a rigid
monolithic architecture to a more flexible architecture where features
can be added without touching the core code. Only features which simply
cannot be implemented with scripting, for example because of efficiency
reasons, should be implemented in the core code.
There are also many other features which would benefit from scripting
support, such as importing and exporting of file formats (how many times
has a converter from POV-Ray to other formats been requested?)
Also, POV-Ray cannot simply drop its scripting language. This is simply
because the scripting language is one of the major features, which
differentiates it from many other similar renderers. I fear that if
POV-Ray was a pure renderer, with no scripting support, it would have
been forgotten long time ago.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp escribió:
> POV-Ray should move from a rigid
> monolithic architecture to a more flexible architecture where features
> can be added without touching the core code. Only features which simply
> cannot be implemented with scripting, for example because of efficiency
> reasons, should be implemented in the core code.
In my opinion, it's currently in a state where it is a rigid monolithic
architecture where adding features even by touching the core code is
very hard. It should start by being flexible there. Then make it scripted.
Adding a pattern, an object, a camera projection, or a different
lighting algorithm shouldn't take months of trying to figure out the
existing code.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nicolas Alvarez <nic### [at] gmailisthebestcom> wrote:
> In my opinion, it's currently in a state where it is a rigid monolithic
> architecture where adding features even by touching the core code is
> very hard. It should start by being flexible there. Then make it scripted.
Making it scripted is exactly the way to move out from being monolithic.
You can't separate these two things.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> No, it's not about what everyone wants, it's about what
> POV-Ray needs.
The Big Picture:
What POV-Ray needs to survive for another 15 years is for a decent
number of people to post high-quality work on places like CGTalk. For
that to happen, the program needs rendering capabilities and users.
Features like shaders (with necessary procedural capabilities), improved
motion-blur, improved AA, nurbs, an accessible scripting language, and
modeller integration will draw more users and allow those and current
users to create more impressive works. Adding clutter (and almost
certainly new bugs) to the interface for the purpose of overlapping the
capabilities of existing, non-renderer tools will not.
The low-level language creating the mid-level language creating the
high-level language (resulting in "#include ... function-call ( ...") is
a programmer's fantasy somewhat like "you can use c++ as a high-level
language if you have the right libraries." Introduce lower-level
programming tools into the SDL for the purpose of coding
mesh-manipulation or text-reading libraries, and these tools will creep
into the high-level (common user) code. The effect of this is that
examples of POV SDL become nearly useless to those not familiar with a
very large portion of the SDL.
> Also, POV-Ray cannot simply drop its scripting language. This is
> simply because the scripting language is one of the major features,
> which differentiates it from many other similar renderers.
Agreed, but this scripting support must be accessible to draw and keep
users.
-Shay
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Warp" <war### [at] tagpovrayorg> wrote in message
news:47040a89@news.povray.org...
> St. <dot### [at] dotcom> wrote:
>> As it happens, from a non-programmers point of
>> view, I think this thread has been a frenzy of what everyone *wants*
>
> No, it's not about what everyone wants, it's about what POV-Ray needs.
Well, yes, that's true.
>
> POV-Ray needs to improve, else it will slowly fade into oblivion.
I'm with you, I understand this.
> There are also many other features which would benefit from scripting
> support, such as importing and exporting of file formats (how many times
> has a converter from POV-Ray to other formats been requested?)
True, many, many, times.
>
> Also, POV-Ray cannot simply drop its scripting language. This is simply
> because the scripting language is one of the major features, which
> differentiates it from many other similar renderers. I fear that if
> POV-Ray was a pure renderer, with no scripting support, it would have
> been forgotten long time ago.
Couldn't we just call Moray 'Pov-Ray', and work with that?
~Steve~
>
> --
> - Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Shay a écrit :
> Agreed, but this scripting support must be accessible to draw and keep
> users.
I second that. Simple things (and moderately complex things) that we do
now with POV 3.6 must remain simple to do in any future development.
However, provided the above, being able to do more complex things, or
doing it with more flexibility, on top of that, is a necessary evolution.
Fabien.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Shay <Sha### [at] cccc> wrote:
> Adding clutter (and almost
> certainly new bugs) to the interface for the purpose of overlapping the
> capabilities of existing, non-renderer tools will not.
For some reason you have this obsessive fixation about "if it can be
done with third-party tools, it should not be added to POV-Ray".
Well, you know what? 3D images can be rendered with third-party programs.
Thus, by your logic, rendering support is not necessary in POV-Ray because
you can do it with other programs.
So what if you can calculate subdivision of meshes with third-party tools.
Can you guess how many of these tools I have in my computer? Moreover, can
you guess how many of these tools are not available at all for my OS?
Besides, even if I had a subdivision-capable program available for my OS,
it would still be clumsy to use. I would have to create or convert the mesh
to a format supported by that program, then I would have to perform the
subdivision, then I would have to export or convert the result to a POV-Ray
mesh, and then I would have to write the SDL file to read that mesh.
Naturally this becomes more complicated if the original mesh was created
with POV-Ray itself (for example I have an include file which creates a
mesh in the shape of a surface of revolution, given the outline spline).
It would be really, really handy if I could perform the subdivision in
POV-Ray itself. No conversions, no saving, no temporary files, no nothing.
Just one command and there you are: I have the subdivided mesh.
Why you think enhancing POV-Ray in a way that allows creating this kind
of functionality is a bad thing goes beyond my comprehension.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
St. <dot### [at] dotcom> wrote:
> Couldn't we just call Moray 'Pov-Ray', and work with that?
No, because Moray is windows-only.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp a écrit :
> St. <dot### [at] dotcom> wrote:
>> Couldn't we just call Moray 'Pov-Ray', and work with that?
>
> No, because Moray is windows-only.
I think he's joking...
Fabien.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp a écrit :
> So what if you can calculate subdivision of meshes with third-party tools.
> Can you guess how many of these tools I have in my computer? Moreover, can
> you guess how many of these tools are not available at all for my OS?
Good example. 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 (thus optimizing memory requirements and rendering time).
It wouldn't be easy to get that with an external tool.
Advanced features such as displacement mapping would also benefit from an
integrated model (well, the list is long).
Of course, there are features that would be better handled externally,
but, before saying "it shouldn't be within POV-Ray", first answer the
question : "won't it be faster or more flexible if done within POV-Ray ?".
Fabien.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Fa3ien <fab### [at] yourshoesskynetbe> wrote:
> Good example. 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 (thus optimizing memory requirements and rendering time).
> It wouldn't be easy to get that with an external tool.
Also: Being able to subdivide using POV-script allows more flexibility.
For example, suppose you want to subdivide the mesh only at parts which
are outside of a given object, but not in parts which are inside. Or you
want to subdivide only at places where the mesh is green.
Those kinds of things would be simply *impossible* with a third-party
tool.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp <war### [at] tagpovrayorg> wrote:
> Fa3ien <fab### [at] yourshoesskynetbe> wrote:
> > Good example. 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 (thus optimizing memory requirements and rendering time).
> > It wouldn't be easy to get that with an external tool.
>
> Also: Being able to subdivide using POV-script allows more flexibility.
>
> For example, suppose you want to subdivide the mesh only at parts which
> are outside of a given object, but not in parts which are inside. Or you
> want to subdivide only at places where the mesh is green.
> Those kinds of things would be simply *impossible* with a third-party
> tool.
>
> --
> - Warp
Can we imagine a fragment of code like this:
my_mesh = mesh { ... } // or: pov.primitive.Mesh.read("body.msh");
my_mesh.nose.subdivide(...);
my_mesh.nose.smooth(...);
Bruno
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Fa3ien" <fab### [at] yourshoesskynetbe> wrote in message
news:47050742$1@news.povray.org...
> Warp a écrit :
>> St. <dot### [at] dotcom> wrote:
>>> Couldn't we just call Moray 'Pov-Ray', and work with that?
>>
>> No, because Moray is windows-only.
>
> I think he's joking...
No, I wasn't, I didn't know that. I have it, but don't use it. Anyway,
why can't it be ported then?
~Steve~
>
> Fabien.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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!
We should have one and only povray SDL and it should have easy syntax and
semantics, should be mostly declarative interspeced with a few useful
control flow commands and should be modular. If someone wishes to program
in another language which suits his needs best, do it and create a program
in said language which compiles his scene or library to povray SDL, just
like today.
I think if povray loses its SDL, it'd lose its identity. If it shipped just
with some sort of bytecode VM for which lots of languages could compile to,
it'd still lose its identity.
Povray needs its SDL, period.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
[1] Maya scripting interface
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp escribió:
> St. <dot### [at] dotcom> wrote:
>> Couldn't we just call Moray 'Pov-Ray', and work with that?
>
> No, because Moray is windows-only.
>
Not necessarily forever ;)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Shay a écrit :
> But how many people are we excluding by obfuscating the SDL?
Who wants to obfuscate the SDL ? I believe (and hope I'm right)
that 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.
> 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).
As I already said, it's all a matter of compromise. POV-Ray's SDL
won't be a "full featured" OO language like C++ or such. I imagine*
there would be :
- no pointers
- only a few data types (we don't need an "integer" type, for example)
- no polymorphism or other advanced brainf***ing technique
- ... ?
(* : Warp, don't jump on this, it's only some vague speculations)
> "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."
POV-Ray's current SDL is already a programming language. There are
loops, conditional, and functional macros. What is needed is mainly to
enhance these, for speed (macros are currently darn slow) and
flexibility. And some object-orientedness won't harm.
> 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.
90% of my scenes (well, when I did scenes) were done in SDL.
95% of my meshes were done by an external app (of course), but
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.
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.
> 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.
Non-users, don't read this, please :-)
Fabien.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Shay a écrit :
> But how many people are we excluding by obfuscating the SDL?
Who wants to obfuscate the SDL ? I believe (and hope I'm right)
that 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.
> 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).
As I already said, it's all a matter of compromise. POV-Ray's SDL
won't be a "full featured" OO language like C++ or such. I imagine*
there would be :
- no pointers
- only a few data types (we don't need an "integer" type, for example)
- no polymorphism or other advanced brainf***ing technique
- ... ?
(* : Warp, don't jump on this, it's only some vague speculations)
> "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."
POV-Ray's current SDL is already a programming language. There are
loops, conditional, and functional macros. What is needed is mainly to
enhance these, for speed (macros are currently darn slow) and
flexibility. And some object-orientedness won't harm.
Before POV 3.0, POV-Ray was pure scripting. You had to use an
external proggy to create a spiral. Imagine that ! When 3.0
and its programming features, though somewhat simplistic, arrived,
a new world opened, just have a look at the images produced before
and after. When 3.1 introduced macros, another new world opened, 3.1
have been the pinnacle. Let's open new worlds again ! Let's go higher !
> 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.
90% of my scenes (well, when I did scenes) were done in SDL.
95% of my meshes were done by an external app (of course), but
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.
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.
> 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.
Non-users, don't read this, please :-)
Fabien.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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.
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
|
|
| |
| |
|
|
|
|
| |
|
|
