Christopher James Huff wrote:
> 
> [...]
> 
> I'm not sure how your selection function works, but it sounds like it is
> used to combine multiple meshes into one variable-detail mesh? That
> would be faster overall, and wouldn't have the seam problems, but is
> rather difficult to implement.

Now you missed my point :-) I was not talking about meshes at all -
isosurfaces have the strong advantage of much lower memory use (only 16
bit per data point - this is quite unbeatable in comparison to a mesh) and
really renders quite fast in this case.

Christoph

-- 
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 28 Feb. 2003 _____./\/^>_*_<^\/\.______

Post a reply to this message

In article <3EAEFE17.CED34C9A@gmx.de>,
 Christoph Hormann <chr### [at] gmxde> wrote:

> Now you missed my point :-) I was not talking about meshes at all -
> isosurfaces have the strong advantage of much lower memory use (only 16
> bit per data point - this is quite unbeatable in comparison to a mesh) and
> really renders quite fast in this case.

How? You can't base an isosurface on a mesh (right now, at least), and 
what do you mean by "data point"? Are you talking about isosurface 
height fields? Height fields have their own disadvantages compared to 
mesh landscapes...no overhangs, etc. And there is a built-in primitive 
which will render much faster. Isosurfaces can avoid the overhang 
problem, but you have to add a procedural component which means the 
height information will only give general shape. The speed gains of a 
mesh or height field could be very significant.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/

Post a reply to this message

Christopher James Huff wrote:
> 
> > Now you missed my point :-) I was not talking about meshes at all -
> > isosurfaces have the strong advantage of much lower memory use (only 16
> > bit per data point - this is quite unbeatable in comparison to a mesh) and
> > really renders quite fast in this case.
> 
> How? You can't base an isosurface on a mesh (right now, at least), and
> what do you mean by "data point"? Are you talking about isosurface
> height fields? [...]

Take a look at the cited posting in p.b.i.  Image map based isosurfaces
are much more powerful than heightfields.

Christoph

-- 
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 28 Feb. 2003 _____./\/^>_*_<^\/\.______

Post a reply to this message

In article <3EAF9B1A.A6D05BB3@gmx.de>,
 Christoph Hormann <chr### [at] gmxde> wrote:

> Take a look at the cited posting in p.b.i.  Image map based isosurfaces
> are much more powerful than heightfields.

I don't do much in p.b.i from here...though this connection is higher 
bandwidth, for some reason it is slower at accessing the newsgroups than 
a dialup connection. I'll check it out though.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/

Post a reply to this message

In article <3EA### [at] freefr>,
 Nicolas Calimet <pov### [at] freefr> wrote:

> > Anyway, it would be 
> > nice if there was a way to put these objects in persistent variables so 
> > they wouldn't have to be reloaded or recalculated for every frame.
> 
> 	I also did it for meshs only in my patch. Works fine. Saves a huge
> amount of time of course...

Sorry, but that looks like a very bad design. True persistent variables 
would be much cleaner and more useful.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/

Post a reply to this message

> Sorry, but that looks like a very bad design. True persistent variables 
> would be much cleaner and more useful.

	Do you mean this by looking at the code or just by the fact I did
so on an object basis ? In my patch I only wanted to have something that
works for the particular object I'm using, since in general it did not
work in MegaPOV. In my case it's not meant to be of general use, but of
simple use like a single keyword to add in the object definition.
	My feeling is that essentially only mesh-based objects really
need some persistent feature, since they are usually the largest object
(am I wrong ?) to parse. But I'd be glad if some general solution would
be inplemented in official/unofficial POV. Again the persistent things
in MegaPOV 0.7 were quite buggy, unfortunately.

	And my patch is _definitely_ not of general use, anyway  ;o)

Post a reply to this message

In article <3EB### [at] freefr>,
 Nicolas Calimet <pov### [at] freefr> wrote:

> > Sorry, but that looks like a very bad design. True persistent variables 
> > would be much cleaner and more useful.
> 
> 	Do you mean this by looking at the code or just by the fact I did
> so on an object basis ?

Neither, I am talking about the syntax. Something like:
#persistent Name = Value;
would be better.


> In my patch I only wanted to have something that
> works for the particular object I'm using, since in general it did not
> work in MegaPOV. In my case it's not meant to be of general use, but of
> simple use like a single keyword to add in the object definition.
> 	My feeling is that essentially only mesh-based objects really
> need some persistent feature, since they are usually the largest object
> (am I wrong ?) to parse. But I'd be glad if some general solution would
> be inplemented in official/unofficial POV. Again the persistent things
> in MegaPOV 0.7 were quite buggy, unfortunately.

If it's going to be implemented, it might as well be done right the 
first time. Having it be a feature of one type of object is limiting, 
inconsistent, and annoying. And your assumption that people will only 
want meshes to persist is just wrong...tree generators, particle or 
physics simulations, etc.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/

Post a reply to this message

> Neither, I am talking about the syntax. Something like:
> #persistent Name = Value;
> would be better.

	Agreed.

> If it's going to be implemented, it might as well be done right the 
> first time.

	Sure, but you probably know quite well that making something
right the very first time, in software development I mean, is either
a piece of luck, or some good time spent to think of it before (and
nobody can think of everything before actually implementing). Maybe
it's even only utopia  :o)

> Having it be a feature of one type of object is limiting, 
> inconsistent, and annoying.

	Yeah. Again I did it for a very specific task. I don't mind
if my patch is not used by anybody but me. I did release it only
because it worked for me, and some (few) found it useful as well.
	In general I perfectly agree with you: to make things as
general as possible, as good as possible. But sometimes it's worth
making some specialized stuff, as a quick working answer to a very
particular situation. I don't intend my little mods to come up into
the official POV anyway...

> And your assumption that people will only 
> want meshes to persist is just wrong...tree generators, particle or 
> physics simulations, etc.

	Okay, I only have a very narrow usage of POV, that's why I
did not think of what you point out -- who said I'm narrow-minded ?  ;-)

	Sounds like those persistent things will require a completely
new POV4 engine ?

	- NC

Post a reply to this message

Thorsten Froehlich wrote:

> In article <3eac5446@news.povray.org> , Wolfgang Wieser <wwi### [at] gmxde>
> wrote:
> 
>> I cannot imagine that.
>> I have to wait >4 minutes to get 1 million triangles parsed
>> on a 1.4 GHz box.
>>
>> Furthermore, you must have more than 4Gb of virtual memory.
> 
> No, that just implies there is something wrong with the data you have.
> Could you show a few pieces of the data here?
> 
No Problem.

It's a simple mesh (not mesh2 which eliminates the need for hash lookups 
and thus parses faster). 

triangle { <0.0145291,-0.00082502,3.33516>,
<0.0145319,-0.000761583,3.33501>, <0,-0,3.33654> }
triangle { <0.0145319,-0.000761583,3.33501>, <0,-0,3.33654>, <0,-0,3.33663>
}
triangle { <0.0145319,-0.000761583,3.33501>,
<0.0145352,-0.000698175,3.33504>, <0,-0,3.33663> }
triangle { <0.0145352,-0.000698175,3.33504>, <0,-0,3.33663>, <0,-0,3.3369> }
triangle { <0.0145352,-0.000698175,3.33504>,
<0.0145391,-0.000634792,3.33528>, <0,-0,3.3369> }
triangle { <0.0145391,-0.000634792,3.33528>, <0,-0,3.3369>, <0,-0,3.33684> }
triangle { <0.0145391,-0.000634792,3.33528>,
<0.0145406,-0.000571301,3.33501>, <0,-0,3.33684> }
triangle { <0.0145406,-0.000571301,3.33501>, <0,-0,3.33684>, <0,-0,3.33669>
}
triangle { <0.0145406,-0.000571301,3.33501>,
<0.0145429,-0.000507851,3.33501>, <0,-0,3.33669> }
triangle { <0.0145429,-0.000507851,3.33501>, <0,-0,3.33669>, <0,-0,3.33666>
}
triangle { <0.0145429,-0.000507851,3.33501>,
<0.0145449,-0.000444387,3.33498>, <0,-0,3.33666> }
triangle { <0.0145449,-0.000444387,3.33498>, <0,-0,3.33666>, <0,-0,3.33687>
}

Anything wrong with the data? :)

Parse time could be increased by using mesh2 but mem usage?

Wolfgang

Post a reply to this message

Christopher James Huff wrote:

> A sphere primitive for the planet. As you get closer, a mesh of the area
> visible from the ship...
>
The switch between these two may be ugly. Mountains pop up suddenly. 
But using a 200k mesh may be fine. 

> a few hundred thousand triangles, maybe a million. 
>
Yes, one million is enough if you see the whole planet. 
A few hundret thousand is okay for 320x240 only. 

> Once you get close to the canyon, switch to a high level of
> detail mesh, the detail will probably require a million or so. 
>
That was what I actually expected to read... However:

One million for the canyon is far too few. The problem is that 
in mid-ragne and in far background, it is okay but the foreground 
looks real ugly. 
(Solution: mixed-grid mesh per frame, but we're here because we wanted 
to avoid it, right? Other solutions? (beyond isosurface))

Here is the actual problem. 

> You could set things up so
> you have one bigger mesh with variable amounts of detail, highest in the
> canyon...simpler 
>
Well, would be feasible if 1e6 triangles were enough for the canyon. 

> but less efficient, but nowhere near as bad as your
> idea of using a full-resolution mesh of an entire freaking planet.
> That is just wasteful on current systems, even if you have the RAM for
> it.
> 
The only feasible alternative I've seen is Christoph's proposal using an 
isosurface image map. 

Wolfgang

Post a reply to this message