 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Hi everyone!
The first super ultra alpha patch of my blob to mesh patch is finally
done. It works ok right now, but I haven't tested it much yet.
I posted a test image in p.b.i so go take a look or just read some more
'bout it there.
Must sleep now... =)
/Anders
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Arne Haglund <arn### [at] tninet se> wrote:
: The first super ultra alpha patch of my blob to mesh patch is finally
: done. It works ok right now, but I haven't tested it much yet.
: I posted a test image in p.b.i so go take a look or just read some more
: 'bout it there.
What are the advantages of converting (internally?) a blob to a mesh?
I can only think of disadvantages (more inaccurate blobs, no interior
(can't be used in csg, etc), takes more memory, slows down the parsing...)
--
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> What are the advantages of converting (internally?) a blob to a mesh?
> I can only think of disadvantages (more inaccurate blobs, no interior
> (can't be used in csg, etc), takes more memory, slows down the parsing...)
I don't know how this guy handles things, but I imagine that the blobs are
quite accurate, esp. with so many triangles as he said he used. About the
clearly defined interior, wasn't there something in either the SuperPatch or
UVPOV that could handle that? Memory consumption most certainly grows, and the
parsing would slow a bit, but I think it's not a bad thing. It could be made
to output to a temporary file in a special folder perhaps to reuse it, and
keep things going fast, besides, the big benefit occurs in rendering times.
That's what we really aim to reduce.
--
Anthony L. Bennett
http://welcome.to/TonyB
Non nova, sed nove.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
TonyB <ben### [at] panamaphoenixnet> wrote:
: the big benefit occurs in rendering times.
: That's what we really aim to reduce.
Is the rendering of a (big) mesh really so much faster that's worth the
efforts?
I think that you will only end mesh^Hsing up things... :)
--
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
TonyB wrote:
>
> > What are the advantages of converting (internally?) a blob to a mesh?
> > I can only think of disadvantages (more inaccurate blobs, no interior
> > (can't be used in csg, etc), takes more memory, slows down the parsing...)
>
> I don't know how this guy handles things, but I imagine that the blobs are
> quite accurate, esp. with so many triangles as he said he used. About the
> clearly defined interior, wasn't there something in either the SuperPatch or
> UVPOV that could handle that? Memory consumption most certainly grows, and the
> parsing would slow a bit, but I think it's not a bad thing. It could be made
> to output to a temporary file in a special folder perhaps to reuse it, and
> keep things going fast, besides, the big benefit occurs in rendering times.
> That's what we really aim to reduce.
>
> --
> Anthony L. Bennett
> http://welcome.to/TonyB
>
> Non nova, sed nove.
If I understand it correctly the advantage of this would be that if you convert
a blob to a mesh you'd have the surface-coordinates (triangles). I guess you
could find those with the trace-function in the Superpatch but with a mesh you'd
have them in a handy format (I hope). I think blobs are great but I've often
wished I could convert them to a mesh, for instance for morphing in an
animation. Let's just hope Arne gets it figured out.
Go, Arne, go!
;-)
Remco
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Remco de Korte <rem### [at] xs4allnl> wrote:
: If I understand it correctly the advantage of this would be that if you convert
: a blob to a mesh you'd have the surface-coordinates (triangles). I guess you
: could find those with the trace-function in the Superpatch but with a mesh you'd
: have them in a handy format (I hope). I think blobs are great but I've often
: wished I could convert them to a mesh, for instance for morphing in an
: animation. Let's just hope Arne gets it figured out.
If I have understood correctly, the patch converts the blob to a mesh
_internally_, that is, after parsing. That is: you don't have access to
the coordinates.
I may be wrong here, though. Please correct me if I am.
--
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nieminen Mika wrote:
>
> Remco de Korte <rem### [at] xs4allnl> wrote:
> If I have understood correctly, the patch converts the blob to a mesh
> _internally_, that is, after parsing. That is: you don't have access to
> the coordinates.
> I may be wrong here, though. Please correct me if I am.
>
Uh-oh, that would spoil all the fun.
Too bad...
It already sounded too good to be true.
Remco
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nieminen Mika wrote:
>
> Is the rendering of a (big) mesh really so much faster that's worth the
> efforts?
> I think that you will only end mesh^Hsing up things... :)
Actually, I think it would be. Rendering time for meshes does not increase
greatly in relation to the number of triangles (a logarithmic algorithm
speed, if I understand correctly), whereas blobs get quite slow when a
large number of elements are used (at least a linear algorigm speed).
So the benifit would probably only be seen in blobs with many elements
and on systems with lots of RAM.
The real benifit here is when this is extended to isosurfaces.
General isosurfaces (and blobs are simply a special type of isosurface)
render fairly slowly in POV under the current implementation, so turning
them into meshes could be a very good thing.
-Nathan
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nathan Kopp <Nat### [at] koppcom> wrote:
: The real benifit here is when this is extended to isosurfaces.
I would like to see how do you triangulate a z=sin(x)+sin(y) surface... :)
--
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nieminen Mika wrote:
>
> Nathan Kopp <Nat### [at] koppcom> wrote:
> : The real benifit here is when this is extended to isosurfaces.
>
> I would like to see how do you triangulate a z=sin(x)+sin(y) surface... :)
>
Ummm, bad example - since that equation is of the form z = f(x, y), you
can parameterize & generate a nice surface quickly. Building a
heightfield from it would also take little time...
Something like this Lundin surface would be better (k, d constant - 0.5
and 1 are nice values):
x - d * sin(k / z))^2 + (y - d * cos(k / z))^2 + z^2 - 1 = 0
The closer to the origin you get, the more the oscillation.
Xander
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
