 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote in message <47076431@news.povray.org>:
> Btw, how do you envision the basic user being able to write shaders in
> this system?
Actually, I do not know exactly what a shader is. Would a basic user be able
to write one, in any system?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nicolas George <nicolas$george@salle-s.org> wrote:
> Warp wrote in message <47076431@news.povray.org>:
> > Btw, how do you envision the basic user being able to write shaders in
> > this system?
>
> Actually, I do not know exactly what a shader is.
A user-definable function that accepts some information about a scene,
object, surface or ray and returns information that the renderer then uses
to modify the shading, illumination, any other aspect of the rendered
image.
I suspect though that the shading language under consideration is solely to
replace only what other packages would call surface shaders: these shaders
accept information about a ray and the object it intersects, and return a
final surface colour using some internal process. POV's support for this is
quite focussed on colour, rather than surface properties; almost that you
can have any BDRF so long as it's Lambert.
> Would a basic user be able to write one, in any system?
Yes. Although the actual shader language is usually quite low-level (often
C-like), and therefore not particularly artist-friendly, most applications
provide a specialised visual editor. These days they are usually based on
nodes (plug a texture node into a diffuse shading node to get a texture
mapped diffuse surface, for example). Some systems opt to use layers, but
it ends up being the same. The systems are very powerful indeed, much more
powerful than my textured diffuse example.
I guess the plan in POV is not to ship any such visual support by default,
and make the underlying shader language artist-friendly enough to use. As
far as I know this will be a unique achievement, both in terms of
originality and, as always, difficulty.
Some further reading:
http://www.janwalter.com/
(the shader writing bits show how a few other packages handle this in their
C-like shading language)
http://www.xsi-blog.com/archives/118
(clever use of the visual shading language to speed up ambient occlusion in
XSI/mental ray)
Tom
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Tom York" wrote in message
<web.47079017bcc3cc027d55e4a40@news.povray.org>:
> A user-definable function that accepts some information about a scene,
> object, surface or ray and returns information that the renderer then uses
> to modify the shading, illumination, any other aspect of the rendered
> image.
<snip>
Ok, thanks.
> Yes. Although the actual shader language is usually quite low-level (often
> C-like), and therefore not particularly artist-friendly, most applications
> provide a specialised visual editor. These days they are usually based on
> nodes (plug a texture node into a diffuse shading node to get a texture
> mapped diffuse surface, for example). Some systems opt to use layers, but
> it ends up being the same. The systems are very powerful indeed, much more
> powerful than my textured diffuse example.
I do not think that can be called "writing" a shader. And what you describe
seems to me quite similar to what is possible already with the numerous
pigments of POV-Ray. Isn't it?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nicolas George <nicolas$george@salle-s.org> wrote:
> I do not think that can be called "writing" a shader. And what you describe
> seems to me quite similar to what is possible already with the numerous
> pigments of POV-Ray. Isn't it?
A shader should be able to, for example, launch additional rays if
necessary.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote in message <47079ed1@news.povray.org>:
> A shader should be able to, for example, launch additional rays if
> necessary.
Yes, I understood that. And I ask again the question, this time more
precisely:
Is, with any system, a basic non-programmer user, capable of writing a
shader that does more that what is possible with textures and pigments?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nicolas George <nicolas$george@salle-s.org> wrote:
> "Tom York" wrote in message
> > Yes. Although the actual shader language is usually quite low-level (often
> > C-like), and therefore not particularly artist-friendly, most applications
> > provide a specialised visual editor. These days they are usually based on
> > nodes (plug a texture node into a diffuse shading node to get a texture
> > mapped diffuse surface, for example). Some systems opt to use layers, but
> > it ends up being the same. The systems are very powerful indeed, much more
> > powerful than my textured diffuse example.
>
> I do not think that can be called "writing" a shader.
Does it matter? As I said, I really doubt POV 4 will include such a visual
editor.
> And what you describe seems to me quite similar to what is possible already
> with the numerous pigments of POV-Ray. Isn't it?
You can look though the archives of this NG to find out. Some of it is not
exactly straightforward. A lot of it is impossible. For an example of the
first, consider a surface whose specularity varies independently of its
roughness. To vary one or the other property requires only a texture_map.
To vary both independently requires two nested levels of texture maps.
That's very clumsy, and hopefully you do not want to vary the diffuse
property as well, or that will be another nesting level working off 8
textures at the lowest level.
For an example of the second, there's plenty of stuff it can't do. Off the
top of my head, apart from launching new rays as Warp suggested (essential
for ambient occlusion), there's ramp/gradient shaders (shaders that can use
the level of illumination to select a colour), using any BDRF apart from
tweaked lambert with tweaked phong specularity, anisotropic highlights. You
can probably find more in the NG archives.
Tom
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nicolas George <nicolas$george@salle-s.org> wrote:
> Is, with any system, a basic non-programmer user, capable of writing a
> shader that does more that what is possible with textures and pigments?
Well, I think that's a bit like asking "is a basic non-programmer user
capable of writing a #while loop which creates 100 objects in a row?"
Often some appropriate mathematics knowledge would be necessary to
perform certain things (such as knowing which direction to shoot a
ray towards), but POV-Ray could provide auxiliary functions to help
with this (in the same way as currently if you need to know the distance
between two points you don't actually need to know the mathematical
formula to do that because POV-Ray offers you the vlength() function
which you can use for this exact purpose).
Sure, if you have no experience nor knowledge about the relevant
mathematics related to computer graphics, it will be quite more difficult
to write shaders. However, some basic things shouldn't be too hard to
create. And what a better way of learning some math while asking how
to do something specific.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nicolas George a écrit :
> Warp wrote in message <47079ed1@news.povray.org>:
>> A shader should be able to, for example, launch additional rays if
>> necessary.
>
> Yes, I understood that. And I ask again the question, this time more
> precisely:
>
> Is, with any system, a basic non-programmer user, capable of writing a
> shader that does more that what is possible with textures and pigments?
No. Not a "non-programmer". Since a shader consists in taking some
input (point position, normal,...), applying some algorithm, and
returning some final value, it's programming.
However, that's someting a beginner prorammer (someone who already
have the aptitude to create a #macro) should be able to do without
learning C++ first.
IMO, ideally, the shading language should be part, or a subset, of
SDL.
Fabien.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Tom York a écrit :
> Nicolas George <nicolas$george@salle-s.org> wrote:
>> "Tom York" wrote in message
>>> Yes. Although the actual shader language is usually quite low-level (often
>>> C-like), and therefore not particularly artist-friendly, most applications
>>> provide a specialised visual editor. These days they are usually based on
>>> nodes (plug a texture node into a diffuse shading node to get a texture
>>> mapped diffuse surface, for example). Some systems opt to use layers, but
>>> it ends up being the same. The systems are very powerful indeed, much more
>>> powerful than my textured diffuse example.
>> I do not think that can be called "writing" a shader.
>
> Does it matter? As I said, I really doubt POV 4 will include such a visual
> editor.
But if there's a propre shading system, there are chances that someone
someday will write a GUI system like the one described to help designing
shaders.
Fabien.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Fa3ien wrote in message <47087cc2$1@news.povray.org>:
> However, that's someting a beginner prorammer (someone who already
> have the aptitude to create a #macro) should be able to do without
> learning C++ first.
Ok, to you and to Warp.
But in the scheme I have described, he would be able to write such a
function in Lua.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nicolas George <nicolas$george@salle-s.org> wrote:
> But in the scheme I have described, he would be able to write such a
> function in Lua.
IMO using an existing scripting language (which is radically different
from the current SDL), which has not been specifically fine-tuned for use
with POV-Ray, should only be done as a last resort, if it becomes clear
that there's no manpower or resources enough to create a designed-for-pov
scripting language.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Fa3ien <fab### [at] yourshoes skynetbe> wrote:
> But if there's a propre shading system, there are chances that someone
> someday will write a GUI system like the one described to help designing
> shaders.
>
> Fabien.
Maybe, depends on the shading language (and on POV4's licensing terms,
although if they do use GPL3 then those will not be an issue). In the
meantime folk'll be stuck writing such things in whatever tertiary language
ends up getting used, under the current plans. I suspect this will annoy
some prospective users of v4, since the one thing that people bother to
mention in the new features of the *renderer* rather than the SDL is more
flexible shading capabilities. If they're inaccessible via the SDL, or at
all inconvenient to use, then many people will think, why bother? Mind you
the suggestions I've seen for the new SDL look so different from the
original SDL that maybe the old user base won't bother with v4 at all.
Tom
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Tom York" <alp### [at] zubenelgenubi34spcom> wrote in message
news:web.4708ba66bcc3cc027d55e4a40@news.povray.org...
> Fa3ien <fab### [at] yourshoesskynetbe> wrote:
>> But if there's a propre shading system, there are chances that someone
>> someday will write a GUI system like the one described to help designing
>> shaders.
>>
>> Fabien.
If they're inaccessible via the SDL, or at
> all inconvenient to use, then many people will think, why bother? Mind you
> the suggestions I've seen for the new SDL look so different from the
> original SDL that maybe the old user base won't bother with v4 at all.
That is exactly what I've been thinking. Yes, whatever 4.0 turns out
to be, I'll give it a go, but if I, (as a PoV layman), can't get to grips
with it, then I'll humbly (and proudly), carry on using 3.5 and mlPoV.
~Steve~
>
> Tom
>
>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Shaders are widely used in game engines. They quicken the process of
shading without the accuracy of actual raytracing.
it's a major component in the ability to render 60fps instead of 1fpd.
It's completely out-of place in POV-Ray because:
1. The math is very mesh-centric
2. There are more photorealistic ways to accomplish the same thing using
radiosity, ambient, and local lighting.
I may be wrong, but how would you mathematically apply a shader to the
surface of say a blob, or an isosurface?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Bryan Valencia <no### [at] waycom> wrote:
> Shaders are widely used in game engines.
They are used in all kinds of renderers. 3D hardware just happens to
have their own standardized (but somewhat limited) shader languages.
> They quicken the process of
> shading without the accuracy of actual raytracing.
That's not actually the purpose of shaders. The purpose of shaders is
to offer a more flexible and powerful way of creating surface texturing.
In other words, instead of having a fixed set of hard-coded texturing
algorithms, a more flexible shader language is offered for creating new
types of texturing.
As I said, shaders are not used exclusively in 3D hardware. They have
been used for quite a long time in many rendering software.
> it's a major component in the ability to render 60fps instead of 1fpd.
Not really. It's just a major component in getting nice texturing
effects. 3D hardware just happens to support a (somewhat limited) shader
language which you can use to create some nice texturing effects, and
naturally they render it quite fast.
However, the images do not render fast *because* of shaders (as you seem
to imply). They render fast *regardless* of shaders. The shaders simply
provide nice texturing effects.
> It's completely out-of place in POV-Ray because:
> 1. The math is very mesh-centric
Incorrect. Shaders are not necessarily at all related to triangle meshes.
I fact, AFAIK, for example renderman shaders are quite independent of the
rendering model used.
Intersection points, normal vectors, texture colors, etc. are not
dependent on the object type used.
> 2. There are more photorealistic ways to accomplish the same thing using
> radiosity, ambient, and local lighting.
You can't achieve everything with those, which you can achieve with
shaders. Besides, shaders can sometimes "fake" things so that they look
convincing but with the advantage of rendering much faster.
> I may be wrong, but how would you mathematically apply a shader to the
> surface of say a blob, or an isosurface?
Easily. Everything a shader needs is information about the intersection
point, normal vector, texture, etc. Nothing of this is dependent on the
type of object used.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Fa3ien wrote:
>
> (for those who wonders, there's no difference between data and
> functions, in LISP)
Your death would be a tragic thing.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
nemesis wrote:
> But, what really bothers me is that I'm not sure povray artists bother about
> writing their own SDLs just to render a scene. I'd be interested to see the
> opinion of guys like Gilles Tran, Jaime Vives, Jim Charter, Tek and other
> advanced SDL users...
>
I'd be happy to comment but I don't understand the question.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> ... very limited and very slow.
>
> Also, from core developement point of view, it's quite horrible.
> For example, why do you think there's no eval() function in POV-Ray?
> That is, a function which takes a string and evaluates this string
> as if it was SDL (similar to how an #include "file" would do, but
> with a string instead)?
> Answer: Because the parser is a mess, full of kludges, burdened with
> backwards-compatibility. For example, #macros are handy and powerful...
> too powerful for their own good. #macros are one of the major reasons
> why there's no eval() function in POV-Ray.
>
> Adding new features to the parser is a real pain sometimes (I have
> recent personal experience), mainly due to how the SDL works and is
> parsed. For example, being able to insert a #declare almost anywhere
> may feel handy, but is a nightmare to parse properly.
> One thing I recently tried to achieve was string concatenation using
> the + operator (as an alternative to the concat function). In the end
> it seems that this would be really, really difficult to implement in
> the current parser due to how interpreting # commands (which can appear
> almost everywhere) works.
>
Warp, this sort of input helps us all understand the issues better.
Thanks for this insight.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Jim Charter a écrit :
> Fa3ien wrote:
>
>
>>
>> (for those who wonders, there's no difference between data and
>> functions, in LISP)
>
> Your death would be a tragic thing.
??? I don't understand well what you mean...
Fabien.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Fa3ien wrote:
> Jim Charter a écrit :
>> Your death would be a tragic thing.
>
> ??? I don't understand well what you mean...
I assume he means that there would be a bad reaction to that big of a
change in the SDL.
- --
William Tracy
afi### [at] gmailcom -- wtr### [at] calpolyedu
You know you've been raytracing too long when you can't visit most Web
sites anymore because you're tired of cleaning the vomit off your keyboard.
-- 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
iD8DBQFHDPMGcCmTzQ++ZncRArQEAJ4nL/H4RKDd05KrJxQO6ZAVV7tb6wCgo8zi
AAIqNh3LKC/d20NNKrtbEuE=
=pUBB
-----END PGP SIGNATURE-----
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
William Tracy wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Fa3ien wrote:
>
>>Jim Charter a écrit :
>>
>>>Your death would be a tragic thing.
>>
>>??? I don't understand well what you mean...
>
>
> I assume he means that there would be a bad reaction to that big of a
> change in the SDL.
>
that's it
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Talking about Visual Studio Express, I have a burning noobie question. Why
do we need a PV editor?
Wouldn't notepad++ 1368051 byte npp.4.4.bin.zip or eclipse do?
I can do Scheme and Prolog on eclipse via plugins.
What is so special that it cannot be done via other editors?
My personal opinion, I think PV editor is not as good, for example,
1. not able to detect file changes promptly
2. syntax coloring is off for unknown extension
3. copy pane is painful
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
zeroin23 wrote:
> Talking about Visual Studio Express, I have a burning noobie question. Why
> do we need a PV editor?
>
> Wouldn't notepad++ 1368051 byte npp.4.4.bin.zip or eclipse do?
> I can do Scheme and Prolog on eclipse via plugins.
>
> What is so special that it cannot be done via other editors?
>
> My personal opinion, I think PV editor is not as good, for example,
> 1. not able to detect file changes promptly
> 2. syntax coloring is off for unknown extension
> 3. copy pane is painful
>
>
>
>
I dunno, I really like it. If for no other reason than the vertical
highlighting ability. And I like an integrated editor that I don't have
to configure myself. It allows me to think about the things I want to
do with POV, the images I want to make, the techniques I want to explore
without nerding around configuring my editing environment 'till the end
of time.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
zeroin23 wrote:
> Talking about Visual Studio Express, I have a burning noobie question. Why
> do we need a PV editor?
>
We don't NEED it (as in mandatory ) but some people like it and some don't.
Some people like the integration and some don't.
> Wouldn't notepad++ 1368051 byte npp.4.4.bin.zip or eclipse do?
> I can do Scheme and Prolog on eclipse via plugins.
>
Any editor will do. Heck , you could even edit a pov file in edlin (that's
for the very old people here :) )
> What is so special that it cannot be done via other editors?
Apart from the integration? Zip, zilch, nothing.
>
> My personal opinion, I think PV editor is not as good, for example,
> 1. not able to detect file changes promptly
> 2. syntax coloring is off for unknown extension
> 3. copy pane is painful
--
Ger
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Jim Charter <jrc### [at] msncom> wrote:
> zeroin23 wrote:
> > Talking about Visual Studio Express, I have a burning noobie question. Why
> > do we need a PV editor?
> >
> > Wouldn't notepad++ 1368051 byte npp.4.4.bin.zip or eclipse do?
> > I can do Scheme and Prolog on eclipse via plugins.
> >
> > What is so special that it cannot be done via other editors?
> >
> > My personal opinion, I think PV editor is not as good, for example,
> > 1. not able to detect file changes promptly
> > 2. syntax coloring is off for unknown extension
> > 3. copy pane is painful
> >
> >
> >
> >
> I dunno, I really like it. If for no other reason than the vertical
> highlighting ability. And I like an integrated editor that I don't have
> to configure myself. It allows me to think about the things I want to
> do with POV, the images I want to make, the techniques I want to explore
> without nerding around configuring my editing environment 'till the end
> of time.
cool didnt know there is vertical highlighting
http://lifehacker.com/software/text/vertical-text-selection-in-microsoft-word-and-beyond-244483.php?mail2=true
by pressing the alt key, you can do that too in word or notepad++
regarding configuration, someone could for example configure one setup
custom just for POV-Ray in notepad++ and done. notepad++ have key stroke
macro which can be very powerful. auto completion is lacking also.
(i understand the pain of setup up an editor, like trying to change netbean
IDE can be quite a pain)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ger <No.### [at] ThankYou> wrote:
> zeroin23 wrote:
>
> > Talking about Visual Studio Express, I have a burning noobie question. Why
> > do we need a PV editor?
> >
> We don't NEED it (as in mandatory ) but some people like it and some don't.
> Some people like the integration and some don't.
>
> > Wouldn't notepad++ 1368051 byte npp.4.4.bin.zip or eclipse do?
> > I can do Scheme and Prolog on eclipse via plugins.
> >
> Any editor will do. Heck , you could even edit a pov file in edlin (that's
> for the very old people here :) )
>
> > What is so special that it cannot be done via other editors?
> Apart from the integration? Zip, zilch, nothing.
>
> >
> > My personal opinion, I think PV editor is not as good, for example,
> > 1. not able to detect file changes promptly
> > 2. syntax coloring is off for unknown extension
> > 3. copy pane is painful
>
> --
> Ger
ic ic.
I am suggesting, instead of maintaining a copy of the editor, why not use
other open source project for it. (adapting or modifying it)
writing an editor to me is an art by itself.
or looking at it at another way, is it possible to allow other application
to hook up with the POV-Ray, writing an interface like to monitor the
updating status of the render, capabilities so that like I can use my
favour editor, but at the same times access to some information in regards
to the render.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
zeroin23 wrote:
>
> My personal opinion, I think PV editor is not as good, for example,
> 1. not able to detect file changes promptly
There is an issue with using CTRL-Z to undo (at least with small numbers
of keystrokes), to the effect that when the number of keystrokes that
were undone equals the number of keystrokes immediately following, the
editor detects the file as "clean" until another key is pressed. I
don't know if this has been fixed in 3.7. To avoid the problem, save
manually after undoing text.
> 2. syntax coloring is off for unknown extension
The first time you save a new file, use "Save As." The POV Team says
that this has been fixed in 3.7.
> 3. copy pane is painful
I find it useful, but I seldom use it--personal preference, I guess. It
could be useful to be able to highlight and copy text directly from the
message pane, but that's a pretty trivial issue for me.
I've been using Visual Studio since version 4. The IDE is nice, but I
have to say that I MUCH prefer the POV editor (especially since meeting
VS 8). But you don't HAVE to use the POV editor--again, it's an issue
of personal preference.
However, people have often asked about running the Windows version of
POV from a command line without opening the editor--is that the real
issue here? I think this would be useful. I've written little VB apps
from time to time to set up things like bicubic patches or whatever,
that would then call POV to render a test scene. In that case, I'd just
as soon not wait for the editor to load, unless I actually want to check
the content of the file I just built.
Just some thoughts...
--Sherry Shaw
--
#macro T(E,N)sphere{x,.4rotate z*E*60translate y*N pigment{wrinkles scale
.3}finish{ambient 1}}#end#local I=0;#while(I<5)T(I,1)T(1-I,-1)#local I=I+
1;#end camera{location-5*z}plane{z,37 pigment{granite color_map{[.7rgb 0]
[1rgb 1]}}finish{ambient 2}}// TenMoons
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Jim Charter nous apporta ses lumieres en ce 2007/10/15 01:25:
> zeroin23 wrote:
>> Talking about Visual Studio Express, I have a burning noobie question.
>> Why
>> do we need a PV editor?
>>
>> Wouldn't notepad++ 1368051 byte npp.4.4.bin.zip or eclipse do?
>> I can do Scheme and Prolog on eclipse via plugins.
>>
>> What is so special that it cannot be done via other editors?
>>
>> My personal opinion, I think PV editor is not as good, for example,
>> 1. not able to detect file changes promptly
>> 2. syntax coloring is off for unknown extension
>> 3. copy pane is painful
>>
>>
>>
>>
> I dunno, I really like it. If for no other reason than the vertical
> highlighting ability. And I like an integrated editor that I don't have
> to configure myself. It allows me to think about the things I want to
> do with POV, the images I want to make, the techniques I want to explore
> without nerding around configuring my editing environment 'till the end
> of time.
Another nice thing with the integrated editor: juse put the cursor on a keyword,
press "F1" and you get the help about that keyword.
--
Alain
-------------------------------------------------
OK, so what's the speed of dark?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I rather like EditPlus - we have adapted it to replace one of our
wretched scripting language editors at work. You can adapt it to use
any help file and you can configure it to syntax highlight based on a
simple list of keywords. We copied and pasted from the help files to
get this list.
we also added in links to windiff and our database dictionary (so
pointing to a field and hitting a hotkey gives us the data definition
for that field.
It seems like we could do the same for POV-Ray.
--
---
Bryan Valencia
- I'd rather live with false hope than with false despair.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Jim Charter <jrc### [at] msncom> wrote:
> nemesis wrote:
>
> > But, what really bothers me is that I'm not sure povray artists bother about
> > writing their own SDLs just to render a scene. I'd be interested to see the
> > opinion of guys like Gilles Tran, Jaime Vives, Jim Charter, Tek and other
> > advanced SDL users...
> >
>
> I'd be happy to comment but I don't understand the question.
neither do I. I got lost in the middle of this long thread... :P
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Just FYI, I never recommended scrapping the SDL or orphaning non-windows
users. All I really wanted was to divorce the editor/parser from the
renderer (not execute the parser/editor).
If that happened the first thing I would do is to make a mesh object
that accepts quads as well as triangles, and has .loadfrom3DS and
.loadfromOBJ methods.
POVMesh myMesh = new POVMESH.loadfrom3DS("Somefile.3DS");
myScene.addObject(myMesh);
--
Bryan Valencia
"I'd rather live with false hope than with false despair."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Bryan Valencia <209### [at] gmailcalm> wrote:
> POVMesh myMesh = new POVMESH.loadfrom3DS("Somefile.3DS");
Why the obsession with 'new'?
How about:
Object o = import3DS("Somefile.3ds");
More abstract, less confusing syntax. No need for useless 'news'.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
how about
public static mesh loadfrom3DS(string filename)
{
//write the code to import 3DS files here.
}
then we can do this:
POVmesh myMesh = loadfrom3DS("somefile.3ds");
//sorry the object keyword is already taken.
---
*runs for cover*
Warp wrote:
> Bryan Valencia <209### [at] gmailcalm> wrote:
>> POVMesh myMesh = new POVMESH.loadfrom3DS("Somefile.3DS");
>
> Why the obsession with 'new'?
>
> How about:
>
> Object o = import3DS("Somefile.3ds");
>
> More abstract, less confusing syntax. No need for useless 'news'.
>
--
Bryan Valencia
"I'd rather live with false hope than with false despair."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Bryan Valencia wrote:
> how about
>
> public static mesh loadfrom3DS(string filename)
> {
> //write the code to import 3DS files here.
> }
>
> then we can do this:
>
> POVmesh myMesh = loadfrom3DS("somefile.3ds");
>
> //sorry the object keyword is already taken.
>
And why would this not be one?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Bryan Valencia nous apporta ses lumieres en ce 2007/10/16 17:39:
> how about
>
> public static mesh loadfrom3DS(string filename)
> {
> //write the code to import 3DS files here.
> }
>
> then we can do this:
>
> POVmesh myMesh = loadfrom3DS("somefile.3ds");
>
> //sorry the object keyword is already taken.
>
>
>
As a mesh IS an object, you can use: object MyMesh = import3DS("MyObject.3ds")
without any problem nor any conflict.
Here, import3DS(...) is a new function that return a mesh object from a .3DS
file. It can have a different name if the developing team prefer, such as:
load3DS, loadfrom3DS, ... or load_object(<object_type>, "Object_Name")
--
Alain
-------------------------------------------------
Where the press is free and every man able to read, all is safe.
Thomas Jefferson
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp <war### [at] tagpovrayorg> wrote:
> Bryan Valencia <209### [at] gmailcalm> wrote:
> > POVMesh myMesh = new POVMESH.loadfrom3DS("Somefile.3DS");
>
> Why the obsession with 'new'?
>
> How about:
>
> Object o = import3DS("Somefile.3ds");
>
> More abstract, less confusing syntax. No need for useless 'news'.
>
> --
> - Warp
In order to keep current syntax spirit, I would rather propose something
like:
my_mesh = mesh
{
load_file {obj "victoria.obj" [obj-specific options]}
//load_file {3ds "zorg.3ds" [3ds-specific options]}
...
[OBJECT MODIFIER (= methods calls? like translate, subdivide ...)]
}
object {my_mesh texture {...}}
Bruno
PS:
The creation block could stand for
Mesh my_mesh = new Primitives.Mesh();
my_mesh.load_obj_file_("victoria.obj", ...);
The object{...} block could stand for
Texture my_mesh_texture = new Texture(...);
my_mesh.setTexture(my_mesh_texture);
Scene.add(my_mesh);
This kind of notation is classical in OO, but not POV-like. I try to find a
notation that ressembles POV, but uses underlying OO features and general
notational principles. Until now, I had no feed back (I hope it does not
mean I am totally wrong ...)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Alain <ele### [at] netscapenet> wrote:
> As a mesh IS an object, you can use: object MyMesh = import3DS("MyObject.3ds")
> without any problem nor any conflict.
> Here, import3DS(...) is a new function that return a mesh object from a .3DS
> file. It can have a different name if the developing team prefer, such as:
> load3DS, loadfrom3DS, ... or load_object(<object_type>, "Object_Name")
The important thing, IMO, is that it doesn't hard-code that what is
returned by the function is precisely a mesh. It should be more abstract
than that.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Bruno Cabasson <bru### [at] alcatelaleniaspacefr> wrote:
> In order to keep current syntax spirit, I would rather propose something
> like:
The problem is that it hard-codes that the imported object is a mesh.
(Can .obj files contain other things too, such as NURBS or whatever?)
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp <war### [at] tagpovrayorg> wrote:
> Bruno Cabasson <bru### [at] alcatelaleniaspacefr> wrote:
> > In order to keep current syntax spirit, I would rather propose something
> > like:
>
> The problem is that it hard-codes that the imported object is a mesh.
> (Can .obj files contain other things too, such as NURBS or whatever?)
>
> --
> - Warp
Well, ok, right, I agree 100% ... But that's not really the problem of the
principle that POV4 syntax should resemble current one. I don't know about
obj format, but the 'load_file' method of meshes can do such an assumption,
and focus on meshes in the file. However, the 'obj specific options' are
here to tell the import method what to do, like access the target object
through its name or whatever obj format is like.
Then, if 'name' is an attribute of obj format:
my_mesh = mesh
{
load_file {obj "victoria.obj" name "victoria_body" [other obj-specific
options]}
...
}
I do not address specific details, but the overall principles of the syntax.
Bruno.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Warp wrote:
> Bruno Cabasson <bru### [at] alcatelaleniaspacefr> wrote:
>> In order to keep current syntax spirit, I would rather propose something
>> like:
>
> The problem is that it hard-codes that the imported object is a mesh.
> (Can .obj files contain other things too, such as NURBS or whatever?)
>
.obj files can't, but other formats can. So how about:
victoria = object {
load_file {obj "victoria.obj" [obj-specific options]}
//load_file {3ds "zorg.3ds" [3ds-specific options]}
...
}
object { victoria }
This would apply to formats that contain other object types, while
keeping a syntax that's closer to the current one.
Jerome
- --
+------------------------- Jerome M. BERGER ---------------------+
| mailto:jeb### [at] freefr | ICQ: 238062172 |
| http://jeberger.free.fr/ | Jabber: jeb### [at] jabberfr |
+---------------------------------+------------------------------+
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
iD8DBQFHFkmxd0kWM4JG3k8RAqF5AKCLBvv5YMinWIdxiPGsJcuIZ7f++wCfTEy/
pkalLzOY4QKdfsLgvKJFOzU=
=6+RN
-----END PGP SIGNATURE-----
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> Alain <ele### [at] netscapenet> wrote:
> The important thing, IMO, is that it doesn't hard-code that what is
> returned by the function is precisely a mesh. It should be more abstract
> than that.
Actually no. I would want a mesh object to be able to load from mesh
data types only (or be created on the fly in SDL like always) I would
never want a CSG union, light source, or bologna sandwich to be able to
load into a mesh, for instance.
The POVMesh object should descend from a POVObject, just like a
POVSphere, POVCylinder, POVBlob, POVUnion, etc. But there should be no
way that a POVCylinder would implement the loadfrom3DS() method.
Keep in mind that the point of this thread is not about things to do to
the SDL to improve it (which should also happen), it's about decoupling
the SDL from the back-end so that we can integrate with more powerful
languages (along with the SDL). The examples I gave were not how I
think the SDL should look at all. I was envisioning what the code would
look like in a fully object-oriented language.
--
Bryan Valencia
"I'd rather live with false hope than with false despair."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> Bruno Cabasson <bru### [at] alcatelaleniaspacefr> wrote:
>> In order to keep current syntax spirit, I would rather propose something
>> like:
>
> The problem is that it hard-codes that the imported object is a mesh.
> (Can .obj files contain other things too, such as NURBS or whatever?)
>
No it's not associating ".obj" with meshes. if you want to import a
NURB, then you would use the POVNurb.loadfromobj("nurbfile.obj");
Maybe better for the mesh would be
POVMesh.LoadFromWavefrontObj("somefile.obj");
--
Bryan Valencia
"I'd rather live with false hope than with false despair."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Bryan Valencia wrote:
> Warp wrote:
>> Bruno Cabasson <bru### [at] alcatelaleniaspacefr> wrote:
>>> In order to keep current syntax spirit, I would rather propose something
>>> like:
>>
>> The problem is that it hard-codes that the imported object is a mesh.
>> (Can .obj files contain other things too, such as NURBS or whatever?)
>>
>
> No it's not associating ".obj" with meshes. if you want to import a
> NURB, then you would use the POVNurb.loadfromobj("nurbfile.obj");
>
> Maybe better for the mesh would be
> POVMesh.LoadFromWavefrontObj("somefile.obj");
>
>
I think the main problem with this approach is that you assume you
always know what is in the file. That is a dangerous assumption if you
write a library. It is also not important from a POV point of view,
whatever it is that you load, you can translate, scale and texture it,
so it is an object.
Warp's question was if .obj files can be anything apart from meshes i.e.
if it can harm if you put the result in a mesh. Technically for an .obj
file there may not be a danger, but conceptually it is wrong because
other files can contain other objects and you don't want .obj loading
routines to behave different from, say, .off files.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Jérôme M. Berger wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Warp wrote:
>> Bruno Cabasson <bru### [at] alcatelaleniaspacefr> wrote:
>>> In order to keep current syntax spirit, I would rather propose something
>>> like:
>> The problem is that it hard-codes that the imported object is a mesh.
>> (Can .obj files contain other things too, such as NURBS or whatever?)
>>
> .obj files can't, but other formats can. So how about:
>
> victoria = object {
> load_file {obj "victoria.obj" [obj-specific options]}
> //load_file {3ds "zorg.3ds" [3ds-specific options]}
>
> ...
> }
>
> object { victoria }
>
> This would apply to formats that contain other object types, while
> keeping a syntax that's closer to the current one.
>
I would say that your line
victoria = object {
should be
#define victoria = object {
Or something similar, because I would like to see a difference between
defining an object that may or may not be used more than once, and
naming an object for future reference. So 'victoria = object {...'
should IMHO also create the object and not only define it as a shorthand
for later reference. (hmm, do I make myself clear?)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
andrel wrote:
> I think the main problem with this approach is that you assume you
> always know what is in the file. That is a dangerous assumption if you
> write a library. It is also not important from a POV point of view,
> whatever it is that you load, you can translate, scale and texture it,
> so it is an object.
> Warp's question was if .obj files can be anything apart from meshes i.e.
> if it can harm if you put the result in a mesh. Technically for an .obj
> file there may not be a danger, but conceptually it is wrong because
> other files can contain other objects and you don't want .obj loading
> routines to behave different from, say, .off files.
Typical behavior in the programming world is that when a mesh tries to
open another file, it acts the same as when you (for instance) try to
open a .wav file in paint. You would get an exception.
If there were a wavefront object file were opened by a
nurb.loadfromobj(), it would raise an exception. The filename is
irrelevant, except to make it a little easier to use the default
file-open dialogs on it.
Think of it this way: if you load an image in POV of type "jpeg" and a
filename of "MyImage.png", the parser barfs. Ditto if you did #include
"command.com".
It would be the same here - the language can't load raw SDL into a Mesh
container.
--
Bryan Valencia
"I'd rather live with false hope than with false despair."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Bryan Valencia <209### [at] gmailcalm> wrote:
> Warp wrote:
> > Bruno Cabasson <bru### [at] alcatelaleniaspacefr> wrote:
> >> In order to keep current syntax spirit, I would rather propose something
> >> like:
> >
> > The problem is that it hard-codes that the imported object is a mesh.
> > (Can .obj files contain other things too, such as NURBS or whatever?)
> >
>
> No it's not associating ".obj" with meshes. if you want to import a
> NURB, then you would use the POVNurb.loadfromobj("nurbfile.obj");
>
> Maybe better for the mesh would be
> POVMesh.LoadFromWavefrontObj("somefile.obj");
>
>
> --
> Bryan Valencia
>
I agree that the 'load' method is specific to the type of object involved.
However, your notation does not appear to me as POV-like. For me, it would
rather be:
nurbs
{
load_file {obj "my_2cv.obj" [nurbs-specific modifiers]}
...
}
and
mesh
{
load_file {obj "victoria.obj" [mesh-specific modifiers]}
...
}
Bruno
PS: These lines would invoke internally (once compiled or while interpreted)
some methods like you say:
POVNurb.loadfromobj("my_2cv.obj"); // Or through an instance of POVNurb
class
POVMesh.loadfromobj("victoria.obj"); // Or through an instance of POVMesh
class
but internally only.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Bryan Valencia wrote:
> andrel wrote:
>> I think the main problem with this approach is that you assume you
>> always know what is in the file. That is a dangerous assumption if you
>> write a library. It is also not important from a POV point of view,
>> whatever it is that you load, you can translate, scale and texture it,
>> so it is an object.
>> Warp's question was if .obj files can be anything apart from meshes
>> i.e. if it can harm if you put the result in a mesh. Technically for
>> an .obj file there may not be a danger, but conceptually it is wrong
>> because other files can contain other objects and you don't want .obj
>> loading routines to behave different from, say, .off files.
>
>
> Typical behavior in the programming world is that when a mesh tries to
> open another file, it acts the same as when you (for instance) try to
> open a .wav file in paint. You would get an exception.
>
> If there were a wavefront object file were opened by a
> nurb.loadfromobj(), it would raise an exception. The filename is
> irrelevant, except to make it a little easier to use the default
> file-open dialogs on it.
>
> Think of it this way: if you load an image in POV of type "jpeg" and a
> filename of "MyImage.png", the parser barfs. Ditto if you did #include
> "command.com".
I agree (apart from the parser barf, that is a runtime error. The
association of an extension to a format is a windows thing and POV isn't)
> It would be the same here - the language can't load raw SDL into a Mesh
> container.
and here we part ;) It may be this way if it were implemented your way,
but my point was that it shouldn't.
Please explain why the user has to know what is in a file when writing a
POV script or library.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <4716501d$1@news.povray.org>, 209### [at] gmailcalm says...
> Warp wrote:
> > Alain <ele### [at] netscapenet> wrote:
> > The important thing, IMO, is that it doesn't hard-code that what is
> > returned by the function is precisely a mesh. It should be more abstrac
t
> > than that.
>
> Actually no. I would want a mesh object to be able to load from mesh
> data types only (or be created on the fly in SDL like always) I would
> never want a CSG union, light source, or bologna sandwich to be able to
> load into a mesh, for instance.
>
> The POVMesh object should descend from a POVObject, just like a
> POVSphere, POVCylinder, POVBlob, POVUnion, etc. But there should be no
> way that a POVCylinder would implement the loadfrom3DS() method.
>
> Keep in mind that the point of this thread is not about things to do to
> the SDL to improve it (which should also happen), it's about decoupling
> the SDL from the back-end so that we can integrate with more powerful
> languages (along with the SDL). The examples I gave were not how I
> think the SDL should look at all. I was envisioning what the code would
> look like in a fully object-oriented language.
>
It might be noted that there are some mesh formats that contain some
additional data, some/all of which "might" be usable as well, so the
result would need to either include commands to "load" those elements
using other commands (which may/may not be a good idea), or import them
at the same time. I.e. the "mesh object" generated would need to also
include those things, like textures, etc., when completed. Obviously
those things need to be accessible later too, in case, for example, you
don't want to use the texture that came with the model. But otherwise,
yes. It wouldn't make much sense for something like "cylinder" to have a
"cylinder.loadfrom3DS" function. In fact, it makes a lot of sense to
only apply the imports for certain types "too" the types that support
them. So, in the case of mesh, you make an empty mesh, then use "its"
import function to get the result.
Mind you this won't work for something like a AutoCAD files, since it
can contain a mess of different data types, not just meshes, so you also
need a sort of "importobjects" function that can generate a table of
objects from the file. You don't one, in that case, a single object,
like some of those horrible converters I tried way back when did, where
it took dozens of distinct objects, like from a CAD file of a human
body, and generated "one" mesh, when the original file had them clearly
subdivided into individual parts. What a mess that was...
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Just to digress a bit, anyone used Eclipse plugin framework before?
I was reading about this game called codeinvader.
[www.alphaworks.ibm.com/tech/codeinvaders]
To start using, i need to dump 2 files into eclipse plugin folder. And
magic, I can use eclipse to start editing for codeinvaders...
why do we need POVSphere that is inherited from POVObject?
The idea is that developers can write plugin, and to interface it
Library{
"name of plugin", "function name", para1, para2, ...
return: ret1, ret2,...
}
in terms of loading data like 3ds or meshes, the above plugin library will
allow programmers to code for it.
I find using import(3ds file) weird, it looks like functional programming,
yet OO at the same time.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
zeroin23 wrote:
> why do we need POVSphere that is inherited from POVObject?
We don't really from a language standpoint, but if you (like me) want to
write a truly OO language then it would be truly useful.
> The idea is that developers can write plugin, and to interface it
> Library{
> "name of plugin", "function name", para1, para2, ...
> return: ret1, ret2,...
> }
It would be more efficient to use an OO language to send stuff directly
to the rendering engine rather than translate it all to SDL and then
parse it back to objects again 0.001 seconds later. You have to know
that once POV parses your script, it is somehow becoming OO in the
bowels of the renderer.
> in terms of loading data like 3ds or meshes, the above plugin library will
> allow programmers to code for it.
That's cool but I want more. I want to monkey with POV's brains! Mwahahaha!
--
Bryan Valencia
"I'd rather live with false hope than with false despair."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
