 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 6/20/2010 2:16 PM, nemesis wrote:
> We're not primitive. We just enjoy using far superior text editors. Both vim
> and emacs kick povray's Windows editor's butt major time, complete with syntax
> highligh, generalized textual completion and user code templates. No point
> degrading. :)
>
> I don't think it'd be useful for povray developers to try to duplicate such
> functionality either, just give us the glorious backend.
I made that statement based on the faulty assumption that Linux users
*do* in fact have a dedicated IDE/frontend.
--
http://isometricland.com
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
SharkD <pos### [at] gmail com> wrote:
> On 6/20/2010 2:16 PM, nemesis wrote:
> > We're not primitive. We just enjoy using far superior text editors. Both vim
> > and emacs kick povray's Windows editor's butt major time, complete with syntax
> > highligh, generalized textual completion and user code templates. No point
> > degrading. :)
> >
> > I don't think it'd be useful for povray developers to try to duplicate such
> > functionality either, just give us the glorious backend.
>
> I made that statement based on the faulty assumption that Linux users
> *do* in fact have a dedicated IDE/frontend.
I know. My point is that we don't need a weak frontend. :)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thorsten Froehlich <tho### [at] trfde> wrote:
> > Native support for mesh-based surface approximations
> You can already do this with a macro. Native support would have no benefit -
> the probable assumption that a high quality mesh would be faster to generate
> and then render compared to a native object (i.e. an isosurface) is incorrect.
Given that meshes which approximate the same shape as a complex CSG
composed of other primitves sometimes renders faster than that CSG object,
I don't see how an isosurface would be even faster than that. On the
contrary, an isosurface with the same shape as the complex CSG most probably
would render at least an order of magnitude slower than the original CSG
object.
Tesselating an isosurface to a mesh would probably be a slow'ish process,
but certainly not slower than rendering the isosurface. Then rendering the
mesh would in most cases be orders of magnitude faster than rendering the
original isosurface (after all, the rendering speed of a mesh is something
like logarithmically related to the amount of triangles, so even really
complex surfaces are going to render quite fast).
Also there are advantages of tesselation other than faster rendering.
Among others, it would open up possibilities to efficiently simulate
non-linear transformations (applying a non-linear transformation to a CSG
is impossible, and on an isosurface makes the rendering slower, while on a
mesh it has little effect because the amount of triangles stays the same),
uv-mapping and exporting shapes to other formats.
Of course the *major* problem here is: Which tesselation algorithm to use,
and how to implement it? And who is going to implement it?
AFAIK the marching triangles algorithm is one of the best in existence
(while the marching cubes algorithm is one of the worst), and it's especially
suited for efficiently tesselating isosurfaces ("efficiently" meaning that it
generates an optimal amount of triangles, creating more on places with high
curvature and less in places with low curvature). It might also be usable
with CSG objects (although there are going to be surprising problems there.)
However, somebody would have to implement it.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 21.06.10 14:30, Warp wrote:
> Thorsten Froehlich<tho### [at] trfde> wrote:
>>> Native support for mesh-based surface approximations
>
>> You can already do this with a macro. Native support would have no benefit -
>> the probable assumption that a high quality mesh would be faster to generate
>> and then render compared to a native object (i.e. an isosurface) is incorrect.
>
> Given that meshes which approximate the same shape as a complex CSG
> composed of other primitves sometimes renders faster than that CSG object,
> I don't see how an isosurface would be even faster than that. On the
> contrary, an isosurface with the same shape as the complex CSG most probably
> would render at least an order of magnitude slower than the original CSG
> object.
Not sure where you read isosurfaces are faster than CSG. Oh well :-(
Thorsten
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
nemesis wrote:
> We're not primitive. We just enjoy using far superior text editors. Both vim
> and emacs kick povray's Windows editor's butt major time, complete with syntax
> highligh, generalized textual completion and user code templates. No point
> degrading. :)
FWIW, I use vim under Windows to do most of my original POV coding. The POV
editor is nice for tweaks once the basic scene is running, tho. :-)
--
Darren New, San Diego CA, USA (PST)
Eiffel - The language that lets you specify exactly
that the code does what you think it does, even if
it doesn't do what you wanted.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thorsten Froehlich <tho### [at] trfde> wrote:
> On 21.06.10 14:30, Warp wrote:
> > Thorsten Froehlich<tho### [at] trfde> wrote:
> >>> Native support for mesh-based surface approximations
> >
> >> You can already do this with a macro. Native support would have no benefit -
> >> the probable assumption that a high quality mesh would be faster to generate
> >> and then render compared to a native object (i.e. an isosurface) is incorrect.
> >
> > Given that meshes which approximate the same shape as a complex CSG
> > composed of other primitves sometimes renders faster than that CSG object,
> > I don't see how an isosurface would be even faster than that. On the
> > contrary, an isosurface with the same shape as the complex CSG most probably
> > would render at least an order of magnitude slower than the original CSG
> > object.
> Not sure where you read isosurfaces are faster than CSG. Oh well :-(
"the probable assumption that a high quality mesh would be faster to
generate and then render compared to a native object (i.e. an isosurface)
is incorrect."
If you claim that rendering an isosurface is faster than generating a
mesh from it and then rendering it, you are also implying that rendering
an isosurface is faster than rendering a (complex) CSG because there are
cases where meshes are faster to render than CSG. If meshes are faster than
CSG and isosurfaces are faster than meshes, it logically follows that
isosurfaces are faster than CSG.
I don't really understand what you base your original claim that
isosurfaces are faster to render than generating a mesh and then rendering
the mesh on.
There may be extreme cases where a really fast isosurface (one which is
extremely simple, ie. has a very low gradient, such as a sphere) is faster
to render than generating a mesh from it and then rendering the mesh because
of the overhead of the tesselation process (after all, the tesselation
algorithm requires some processing itself). However, that probably only
happens in extremely simple cases.
In more complex cases tesselating the isosurface is more or less akin
to rendering it at low resolution (because usually it's enough to generate
a mesh which has triangles larger than pixels when projected onto the final
image). Also, when tesselating the isosurface probably needs to be solved
once per mesh vertex, while rendering it might be involve solving it several
times per pixel (eg. in self-reflection, refraction and shadowing situations).
If ray-mesh intersections are faster to compute than ray-isosurface
intersections, then in these cases tesselation + mesh rendering ought to
be faster than direct isosurface rendering.
Even *if* for some reason tesselating the isosurface would be significantly
slower than rendering it, there may still be advantages of doing that because
the resulting mesh can be stored in a file and then read from there in
subsequent renders. Hence even in that case tesselation would be useful.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 21.06.10 18:01, Warp wrote:
>>> Given that meshes which approximate the same shape as a complex CSG
>>> composed of other primitves sometimes renders faster than that CSG object,
>>> I don't see how an isosurface would be even faster than that. On the
>>> contrary, an isosurface with the same shape as the complex CSG most probably
>>> would render at least an order of magnitude slower than the original CSG
>>> object.
>
>> Not sure where you read isosurfaces are faster than CSG. Oh well :-(
>
> "the probable assumption that a high quality mesh would be faster to
> generate and then render compared to a native object (i.e. an isosurface)
> is incorrect."
>
> If you claim that rendering an isosurface is faster than generating a
> mesh from it and then rendering it, you are also implying that rendering
> an isosurface is faster than rendering a (complex) CSG because there are
> cases where meshes are faster to render than CSG. If meshes are faster than
> CSG and isosurfaces are faster than meshes, it logically follows that
> isosurfaces are faster than CSG.
A very interesting conjecture. However, I have a real life, so you will have
to discuss your conjecture with someone else.
Thorsten
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 21.06.10 18:01, Warp wrote:
>>> Given that meshes which approximate the same shape as a complex CSG
>>> composed of other primitves sometimes renders faster than that CSG object,
>>> I don't see how an isosurface would be even faster than that. On the
>>> contrary, an isosurface with the same shape as the complex CSG most probably
>>> would render at least an order of magnitude slower than the original CSG
>>> object.
>
>> Not sure where you read isosurfaces are faster than CSG. Oh well :-(
>
> "the probable assumption that a high quality mesh would be faster to
> generate and then render compared to a native object (i.e. an isosurface)
> is incorrect."
>
> If you claim that rendering an isosurface is faster than generating a
> mesh from it and then rendering it, you are also implying that rendering
> an isosurface is faster than rendering a (complex) CSG because there are
> cases where meshes are faster to render than CSG. If meshes are faster than
> CSG and isosurfaces are faster than meshes, it logically follows that
> isosurfaces are faster than CSG.
A very interesting conjecture. However, I have a real life, so you will have
to discuss your conjecture with someone else.
Thorsten
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 6/20/2010 7:10 AM, Thorsten Froehlich wrote:
>> Sure. And until then there's no reason for its removal from bugtracker.
>
> Its not removed. It is closed. All closed bugs are still visible.
Fine. Then there's no reason for it to be _closed_ on bugtracker. Smart guy.
--
http://isometricland.com
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 6/21/2010 1:03 PM, Thorsten Froehlich wrote:
> A very interesting conjecture. However, I have a real life, so you will
> have to discuss your conjecture with someone else.
>
> Thorsten
Great. So items on bugtracker will survive based on whether a person has
time in "real life" or, as implied in the other thread, on the attitude
of the person who submitted the item. That sounds EXACTLY like the
intended purpose of a software bug tracking system. In fact, why not
also delete SVN branches because said person mentioned something about
your mother?
--
http://isometricland.com
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
