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