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

Post a reply to this message

Samuel Benge <stb### [at] THIShotmailcom> wrote:
> While we're talking about it, please, please, please, add support for
> subdivision of meshes!

Which is the single most important thing about it that make it useful to
you? The reduction of parsing time, file size (and memory use?), or the way
it tends to fix mesh rendering artifacts in the present code? Or something
else?

Tom

Post a reply to this message

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.

  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.

  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.

-- 
                                                          - Warp

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


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.

Rendering and editing are 2 different processes, IMHO.

-- 
---
Bryan Valencia

- I'd rather live with false hope than with false despair.

Post a reply to this message

Bryan Valencia <no### [at] waycom> wrote:
> Rendering and editing are 2 different processes, IMHO.

  1) Surface subdivision is not editing. It's rendering.

  2) You *are* editing when you write SDL, whatever you write.
Wrote a 'translate'? You are editing. Wrote a 'pigment'? You are
editing.

-- 
                                                          - Warp

Post a reply to this message

Tom York wrote:
> Samuel Benge <stb### [at] THIShotmailcom> wrote:
>> While we're talking about it, please, please, please, add support for
>> subdivision of meshes!
> 
> Which is the single most important thing about it that make it useful to
> you? The reduction of parsing time, file size (and memory use?), or the way
> it tends to fix mesh rendering artifacts in the present code? Or something
> else?

1. The reduction of parsing time
2. The small file size of the target mesh (this involves low parsing times)
3. Ease of use
  a. Automatically smooths non-smooth meshes, if you want it
  b. Create complex shapes which would normally render very slowly with 
isosurfaces

All justifiable arguments, IMO.

Sam

Post a reply to this message

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?

>   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 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

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.   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 didn't say I wanted it as a default. Just as an option. You don't use 
a feature unless you know what to expect, and the docs would give plenty 
of warning about using high subdivision values.

But, after reading Warp's reply, I think this would be better as a 
library a person could aquire, if POV supports core scripting in the future.

> Rendering and editing are 2 different processes, IMHO.

It would be akin to making a 3-dimensional loop with thousands (or 
millions) of objects. It would be easier to screw up, but the impact 
would be the same.

Sam

Post a reply to this message

-----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?

- --
William Tracy
afi### [at] gmailcom -- wtr### [at] calpolyedu

You know you've been raytracing too long when you decide to stop testing
that wonderful recursive structure you've created and so you bump up the
recursion level for that final overnight render and go to bed. Next
morning you wonder why the swap file has grown to nearly 450mb, your
hard disk is making dying noises and pov is *still* parsing.
    -- fish-head
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHBXuBcCmTzQ++ZncRAp/xAJ9NpB6ZAlwTjfxt7gQXQoYe1FMa2QCeLoGS
7Y1oH5E/TWPfBhYH9xkyZ3g=
=eu3a
-----END PGP SIGNATURE-----

Post a reply to this message

William Tracy <wtr### [at] calpolyedu> 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