Thomas de Groot <tho### [at] degrootorg> wrote:
> On 22-8-2017 10:45, Stephen wrote:

> > Never the less, just out of idle curiosity. It would be interesting to
> > see the results of some tests.

Yes, that was the primary motivation for posting the link, and I thought that
VTK looked like it was an interesting modeler that some folks might find useful.
 It had some fancy tools like Voronoi and Delaunay that has historically been of
interest to certain Povvers.


> However, there is one point I do not like about the mesh3: it is a
> binary format and so not editable as mesh2 is. I find that a serious
> disadvantage.

My thought there was that the mesh could be SAVED as mesh3 for USE, and if it
needed to be edited, then I'm sure there would be a way to save it back to mesh2
and then convert back again.   My understanding of meshes is that most of them
are so large that they are primarily used as static models.
Even a small speed increase could add up to a large time savings for animators.

I really have to get a Linux box up and running....

Post a reply to this message

On 22/08/2017 13:03, Bald Eagle wrote:
>> However, there is one point I do not like about the mesh3: it is a
>> binary format and so not editable as mesh2 is. I find that a serious
>> disadvantage.
> My thought there was that the mesh could be SAVED as mesh3 for USE, 

That's the way I'm thinking. "Finalise" it.


>and if it
> needed to be edited, then I'm sure there would be a way to save it back to mesh2
> and then convert back again.   My understanding of meshes is that most of them
> are so large that they are primarily used as static models.

If you make animations you use a series of meshes.

> Even a small speed increase could add up to a large time savings for animators.
> 

It could indeed.

> I really have to get a Linux box up and running....
> 
> 

Is that a non sequitur?


-- 

Regards
     Stephen

Post a reply to this message

Stephen <mca### [at] aolcom> wrote:

> If you make animations you use a series of meshes.

If the meshaes are animated.   If the scene containing the static meshes is
animated, then no (not necessarily).


> > I really have to get a Linux box up and running....

> Is that a non sequitur?

No.
Non Sequitur is a clever comic strip.

VTK runs on a Unix-style OS, as do many other cool programs I'd like to try, as
well as things I need to compile from source, so I just need to bite the 0.375
H&H Magnum and buy a new [and fast] computer.

I hope your HDD woes are coming to an end.

Post a reply to this message

Le 17-08-22 à 07:00, Thomas de Groot a écrit :
> On 22-8-2017 10:45, Stephen wrote:
>> On 22/08/2017 07:43, Thomas de Groot wrote:
>>> On 22-8-2017 0:05, Sven Littkowski wrote:
>>>> On 21.08.2017 17:06, Stephen wrote:
>>>>> On 21/08/2017 21:30, Sven Littkowski wrote:
>>>>>>>
>>>>>> And how to create MESH3 meshes?
>>>>>> Instructions needed.
>>>>>>
>>>>>
>>>>> Why would you want to if only the patched version can use them?
>>>>>
>>>>>
>>>> Because I always like to try out patched versions, and if there is a
>>>> speed bonus, why not to try?
>>>>
>>>
>>> However, I seriously question the /meaning/ of that "speed bonus". 
>>> After all, it is what the original maker (as cited by Bald Eagle) 
>>> tells us. My experience is that there is nothing wrong with the 
>>> "speed" of huge mesh2 files, so I would not even take the trouble.
>>>
>>
>> Never the less, just out of idle curiosity. It would be interesting to 
>> see the results of some tests.
>>
>> I agree that there is nothing wrong with the speed of mesh2 in PovRay. 
>> But if there were a significant speed up another propriety format 
>> wouldn't blow up the world.
>>
>> We could put in a feature request for Pov Ver 4.0
>>
>>
> That might be an idea indeed.
> 
> However, there is one point I do not like about the mesh3: it is a 
> binary format and so not editable as mesh2 is. I find that a serious 
> disadvantage.
> 

As I see it, there should be no gain while rendering, but potentially a 
big gain while parsing as you need to load the mesh definition from a 
file. Smaller file = faster loading. Also, as the mesh3 seems to be 
preparsed, that's another step where a gain in speed couls appen.
Could be a nice improvement in an animation that otherwise renders rapidly.

Post a reply to this message

On 22/08/2017 21:24, Bald Eagle wrote:
> Stephen <mca### [at] aolcom> wrote:
> 
>> If you make animations you use a series of meshes.
> 
> If the meshaes are animated.   If the scene containing the static meshes is
> animated, then no (not necessarily).
> 
>

Semantics is rearing its ugly head, I think. I read it as animated, 
animatable meshes.


>>> I really have to get a Linux box up and running....
> 
>> Is that a non sequitur?
> 
> No.
> Non Sequitur is a clever comic strip.
> 
> VTK runs on a Unix-style OS, as do many other cool programs I'd like to try, as
> well as things I need to compile from source, so I just need to bite the 0.375
> H&H Magnum and buy a new [and fast] computer.
> 

I see. Makes sense now.

> I hope your HDD woes are coming to an end.
> 

Thanks, it is albeit slowly.
I'm on my initial backup after cloning the drive, for the second time.

I'll do it right if it kills me.

-- 

Regards
     Stephen

Post a reply to this message

On 22-8-2017 23:16, Alain wrote:
> As I see it, there should be no gain while rendering, but potentially a 
> big gain while parsing as you need to load the mesh definition from a 
> file. Smaller file = faster loading. Also, as the mesh3 seems to be 
> preparsed, that's another step where a gain in speed couls appen.
> Could be a nice improvement in an animation that otherwise renders rapidly.
> 
> 

@ Alain, Stephen, BaldEagle: Your points are well taken. I stand 
corrected :-)

-- 
Thomas

Post a reply to this message

On 22.08.2017 07:00, Thomas de Groot wrote:
> On 22-8-2017 10:45, Stephen wrote:
>> On 22/08/2017 07:43, Thomas de Groot wrote:
>>> On 22-8-2017 0:05, Sven Littkowski wrote:
>>>> On 21.08.2017 17:06, Stephen wrote:
>>>>> On 21/08/2017 21:30, Sven Littkowski wrote:
>>>>>>>
>>>>>> And how to create MESH3 meshes?
>>>>>> Instructions needed.
>>>>>>
>>>>>
>>>>> Why would you want to if only the patched version can use them?
>>>>>
>>>>>
>>>> Because I always like to try out patched versions, and if there is a
>>>> speed bonus, why not to try?
>>>>
>>>
>>> However, I seriously question the /meaning/ of that "speed bonus".
>>> After all, it is what the original maker (as cited by Bald Eagle)
>>> tells us. My experience is that there is nothing wrong with the
>>> "speed" of huge mesh2 files, so I would not even take the trouble.
>>>
>>
>> Never the less, just out of idle curiosity. It would be interesting to
>> see the results of some tests.
>>
>> I agree that there is nothing wrong with the speed of mesh2 in PovRay.
>> But if there were a significant speed up another propriety format
>> wouldn't blow up the world.
>>
>> We could put in a feature request for Pov Ver 4.0
>>
>>
> That might be an idea indeed.
> 
> However, there is one point I do not like about the mesh3: it is a
> binary format and so not editable as mesh2 is. I find that a serious
> disadvantage.
> 
I see it this way: with some other raytracer, a complicated Mesh has
been created, and is now as "Mesh3" exported, just for rendering with
POV-Ray as part of a bigger and more complex scene.

---
Diese E-Mail wurde von AVG auf Viren geprüft.
http://www.avg.com

Post a reply to this message

I also found this link to be an interesting commentary on POV-Ray and binary
mesh formats:

http://wiki.povray.org/content/Knowledgebase:Files_and_formats#Topic_6

"Why are triangle meshes in ASCII format? They are huge! A binary format would
be a lot smaller. If POV-Ray can read binary images, why couldn't it read binary
mesh data?
It's not as simple as you may think.
You can't compare binary mesh data with image files. Yes, images are binary
data, but there is one big difference: Image files use integer numbers (usually
bytes, in some cases 16-bit integers), which can be easily read in any system.
However, meshes use floating point numbers.
It might come as a bit of surprise that it's far from easy to represent them in
binary format so that they can be read in every possible system.
It's very important to keep in mind that POV-Ray is intended to be a very
portable program, which should be compilable in virtually any system with a
decent C compiler. This is not just mumbo-jumbo; POV-Ray IS used in a wide
variety of operating systems and computer architectures, including Windows,
MacOS, Linux, (Sparc) Solaris, Digital Unix and so on.
The internal representation of floating point numbers may differ in number of
bits and bits reserved for each part of the number inside the data type in
different systems. There's also the infamous big-endian/low-endian problem (that
is, although the floating point numbers were identical in two different systems,
they may be written in different byte-order when writing to a file).
If you try to make carelessly a patch which reads and writes floating point
numbers in binary format, you'll probably quickly find that your patch only
works in a certain architecture only (eg. PC) and not others.
In order to store floating point numbers so that they can be read in any system,
you have to store them in an universal format. ASCII is as good as any other.
However, you are not completely out of luck when dealing with compressing mesh
data. This has been done before. For example check:
http://povrayinclude.wytraven.com/pcm.html
[LINK IS BROKEN - BW]
POV-Ray 3.5 supports a new type of mesh (called mesh2) which stores the mesh
data in a more compact format (similar to the one used in the PCM format
described in the abovementioned link, but with a bit more syntax around it)."

Post a reply to this message

hi,

On 23/08/2017 12:54, Bald Eagle wrote:
> "Why are triangle meshes in ASCII format? They are huge! A binary format would
> be a lot smaller. If POV-Ray can read binary images, why couldn't it read binary
> mesh data?
> It's not as simple as you may think.
> You can't compare binary mesh data with image files. ...

an easy compromise coming to mind is storing the ASCII mesh data
compressed and POVRay decompressing on read; and there are many
well-supported free libraries for the job: gzip, zlib, etc

handling floats in binary, compatibly across platforms, is .. hard.

Post a reply to this message

On 23-8-2017 13:54, Bald Eagle wrote:
> [snip]
> However, you are not completely out of luck when dealing with compressing mesh
> data. This has been done before. For example check:
> http://povrayinclude.wytraven.com/pcm.html
> [LINK IS BROKEN - BW]
> POV-Ray 3.5 supports a new type of mesh (called mesh2) which stores the mesh
> data in a more compact format (similar to the one used in the PCM format
> described in the abovementioned link, but with a bit more syntax around it)."
> 

pcm! I remember that one and used it happily many years ago, especially 
in the times of Moray. It did an excellent job on compression meshes and 
parsing times were wonderfully shortened. Did it convert to mesh2? I 
don't really remember... I think I still have it somewhere, gathering 
dust. Not sure if it is still functional.

After a little digging found that it was created by Warp and included 
into Chris Colefax's site. One of the available WayBackMachine pages is: 
https://web.archive.org/web/20000226171710/http://geocities.com:80/SiliconValley/Lakes/1434/pcm.html



-- 
Thomas

Post a reply to this message