 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
William Tracy <wtr### [at] calpoly edu> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Warp wrote:
> > What should be added is a new scripting language which makes it easy
> > to create mesh subdivision libraries (among many, many other thigns).
>
> Okay, we want an SDL that is fast, simple/easy to learn, and
> flexible/extensible.
>
> I'm wondering if maybe the best way to achieve the third goal is not
> through SDL, but by adding a plugin architecture to POV. The plugins
> would presumably be written in C++; they would be fast and flexible, and
> there would be no "polluting" of the SDL. You could modify and
> redistribute plugins without having to build custom versions of POV.
>
> The big downsides that I see are that the plugins would have to be
> recompiled for each architecture, and the possibility of malicious
> plugins. Both of these might be fixed via a scripted or
> bytecode-compiled language (Java comes to mind, naturally).
>
> Comments?
The architecture I proposed allows plugins to be defined, independant of
platform and OS because there is a high-level intermediate language that is
Java. Plugins could be pieces of code that are coded following rules that
comply the relationship between SDL and the rendering engine. JIT'ed Java
is quick enough for plugins or callable user code. It also facilitates to
have a debugging feature during parse time AND render time. See my chart in
a previous post.
Whatever the language will be, if some user-defined feature and its
implementation are satisfactory, it can then be envisionned to 'hardcode'
it within the core system in a future official release, and make it a
built-in feature rather than a plug-in or 'library component'. All systems
evolve that way, more or less, in my experience.
Shipping POV4 with a standard JRE (or a specific subset) is absolutely not
much of a problem, I think.
Bruno
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Bryan Valencia wrote:
> in my opinion, that antithetic to the whole POV mindset.
> When I create a triangle mesh in POV, I want it to be exactly
> what I describe.
A subdivision surface is no less "exactly what (you) describe" than a
nurb or bicubic patch or blob.
-Shay
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> I'm wondering if maybe the best way to achieve the third goal is not
> through SDL, but by adding a plugin architecture to POV. The plugins
> would presumably be written in C++; they would be fast and flexible, and
> there would be no "polluting" of the SDL. You could modify and
> redistribute plugins without having to build custom versions of POV.
And a possible C++ plugin could be a Python interpreter, so that way
you're already allowing almost any language.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> What should be added is a new scripting language which makes it easy
> to create mesh subdivision libraries (among many, many other thigns). This
> has tons of advantages. For one, it keeps the core code simpler, reducing
> overhead, maintenance requirements and clutter. Another is that hard-coding
> such a feature in the core code would make it rigid and unmodifiable, while
> making it in scripting makes it more flexible and easier for anyone to
> modify for their needs.
Starting from the current set of POV-Ray features, can you establish a
quick list of what stays in core vs. what gets in external libraries ?
Fabien.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> in my opinion, that antithetic to the whole POV mindset. When I create
> a triangle mesh in POV, I want it to be exactly what I describe. Since
> POV doesn't natively allow editing of meshes except as text, I don't
> want the rendering engine changing my 300 triangle mesh into a 6000
> triangle mesh.
I you don't want it, don't do it, but I can assure you that many people
would be delighted to be able to do it.
Or should we remove CSG of meshes because it changes the mesh's appearance ?
> Rendering and editing are 2 different processes, IMHO.
We should get rid if "trace", then ?
The strenght of POV-Ray is into the integration of the scene's
description and the renderer. This should be enforced, not weakened.
Fabien.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Samuel Benge wrote:
> While we're talking about it, please, please, please, add support for
> subdivision of meshes!
>
> Some of us are just no good at the complex routines required to smooth
> meshes ourselves. It would be *much* easier if we could just put some
> triangles together and apply subdivision to it.
>
> Xiaobin Wu and Jianhua Fan's POV-Sub patch is almost perfect. You can
> apply smoothness without subdivision if you want, it works with
> uv_mapping, it parses quickly, and would just make my life easier all
> the way around if it was part of the official version of POV. Or at
> least part of Mega-Pov (subdivision+aoi pigment would be great together).
>
> There are a couple of bugs with the program, however. I can post the bug
> reports over in p.u.patches, if anyone is interested.
>
> So how about it?
>
> Sam
Although it is not a patch or a macro you can use PoseRay
(http://mysite.verizon.net/sfg0000/). It can subdivide meshes preserving
UV mapping, mesh edges, material boundaries and mesh creases. It can
create a mesh2 object of the subdivided mesh for you to use in your scenes.
later,
FlyerX
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Samuel Benge <stb### [at] thishotmailcom> wrote:
> Well, a new scripting language sounds better to me! Such a language
> would allow a person to create their own shaders, right? Say I wanted to
> make an ambient occlusion shader, would I be able to do it with such
> scripting capabilities?
If the scripting language is well designed, hopefully so.
> I'll read up on the recent posts, to see what ideas people have
> presented. Do you think a new scripting language will become a part of
> POV someday?
I hope so.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
William Tracy wrote:
>
> I'm wondering if maybe the best way to achieve [flexibility/extensibility]
> is not through SDL, but by adding a plugin architecture to POV. The plugins
> would presumably be written in C++; they would be fast and flexible, and
> there would be no "polluting" of the SDL. You could modify and redistribute
> plugins without having to build custom versions of POV.
I like this idea.
>
> The big downsides that I see are that the plugins would have to be
> recompiled for each architecture, and the possibility of malicious
> plugins.
Not so much of a downside. If functionality will be taken out of the
main source code and transferred to extensions as Warp suggests, then a
set of official plugins would likely be distributed, compiled, with the
official POV binaries.
-Shay
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Samuel Benge nous apporta ses lumieres en ce 2007/10/04 19:28:
> Warp wrote:
>> Samuel Benge <stb### [at] thishotmailcom> wrote:
>>> While we're talking about it, please, please, please, add support for
>>> subdivision of meshes!
>>
>> No, subdivision of meshes should not be added. That would only worsen
>> the core code overhead.
>>
>> What should be added is a new scripting language which makes it easy
>> to create mesh subdivision libraries (among many, many other thigns).
>> This
>> has tons of advantages. For one, it keeps the core code simpler, reducing
>> overhead, maintenance requirements and clutter. Another is that
>> hard-coding
>> such a feature in the core code would make it rigid and unmodifiable,
>> while
>> making it in scripting makes it more flexible and easier for anyone to
>> modify for their needs.
>
> Well, a new scripting language sounds better to me! Such a language
> would allow a person to create their own shaders, right? Say I wanted to
> make an ambient occlusion shader, would I be able to do it with such
> scripting capabilities?
It's one of the goals of the new proposed scripting language.
>
>> From the end user point of view there isn't much of a difference.
>> However,
>> from the developers' point of view, as well as from the point of view of
>> those who have the knowledge and skill to write such libraries, it would
>> be way, way better.
>
> I'll read up on the recent posts, to see what ideas people have
> presented. Do you think a new scripting language will become a part of
> POV someday?
It looks like it's in the plans.
>
>> It also makes much easier for this kind of thing to happen:
>>
>> "Hey, the subdivision library is great, but I can't do this specific
>> thing with it. Could someone help?"
>> "Here, use this modified version."
>> "Hey, thanks! It works perfectly!"
>>
>> If it was implemented in the core code, then tough luck.
>
> Your arguments make a lot of sense. I hope such a scripting language is
> implemented into a future version of POV!
>
> ~Sam
>
--
Alain
-------------------------------------------------
I believe that banking institutions are more dangerous to our liberties than
standing armies. Already they have raised up a monied aristocracy that has
set the government at defiance. The issuing power should be taken from the
banks and restored to the people to whom it properly belongs.
Thomas Jefferson
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Samuel Benge wrote:
> While we're talking about it, please, please, please, add support for
> subdivision of meshes!
>
> Some of us are just no good at the complex routines required to smooth
> meshes ourselves. It would be *much* easier if we could just put some
> triangles together and apply subdivision to it.
http://www.geocities.com/evilsnack/nsss.htm
This is a macro suite that supplies everything you've asked for (and
allows quadrilateral faces in the mesh you give to it). It may not
parse as fast as you want, but aside from that it should meet your needs.
It works with my LionSnake modeler at
http://www.geocities.com/evilsnack/lionsnake.htm
so that you can make posable models as well.
I am presently working on an upgrade to the modeler and the macro suite
to support faces with any number of sides. This is competing with my
next animation and my Diablo II addiction, so progress has been rather
slow...
Regards,
John
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
