Warp wrote:
>   Have you tried with the beta2 version of the program yet?
> 
I have done some further testing of the program and there seems to be a 
further problem.

The pcm files generated do not seem to parse properly in POV

If I wrap the pcm mesh as an object:
#include "pcm.mcr"
object { read_mesh ( filename.pcm ) texture... }

it will not parse

" } found, object expected "

If I wrap the pcm mesh as an union:
#include "pcm.mcr"
union { read_mesh ( filename.pcm ) texture... }

It will parse but will not display

The test files are in p.b.s-f.

Post a reply to this message

Jim Charter <jrc### [at] msncom> wrote:
> The pcm files generated do not seem to parse properly in POV

  If it starts with "PCM4" then it shouldn't. Chris hasn't updated the
macros to support the new format yet.

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

Post a reply to this message

I didn't realize the normal_indices and uv_indices blocks are optional.
I fixed that.
  I also fixed a problem with the option "ignore keyword 'mesh'" not
being reset between runs.

http://www.cs.tut.fi/~warp/WinMeshcomp30_beta3.zip

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

Post a reply to this message

...
>   I also fixed a problem with the option "ignore keyword 'mesh'" not
> being reset between runs.

Using WinMeshcomp30_beta3.zip
Something that looks similar is if I make a selection in the
Transformations tab(Print boundaries), Optimizing is not done (as explained
in the text file). If I clear the Transformations, Optimizing is still not
done, I have to restart the program.

Or is there another way to do this?

Stephen

Post a reply to this message

StephenS <ssh### [at] ottawanet> wrote:
> Using WinMeshcomp30_beta3.zip
> Something that looks similar is if I make a selection in the
> Transformations tab(Print boundaries), Optimizing is not done (as explained
> in the text file). If I clear the Transformations, Optimizing is still not
> done, I have to restart the program.

  That's probably something I forgot to reset as well. I'll look into it.

-- 
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  - Warp -

Post a reply to this message

I updated the zip file.
  It was indeed so that transformations weren't reset between runs. (It's
so much easier with the command-line version because it's run once and
that's it... :) )

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

Post a reply to this message

>   I updated the zip file.
...
When the program is working on a large file(Optimizing), I can't go to
another program (POV-Ray) and back to check if it's done. The WinMeshcomp
window is unresponsive.

As a reference file I'm using:
Ingo's 'Meshmerizing Mesh Maker Macros package'
mesh_demo\p_sphere.pov
changing line 27
from: 200,100,""
to: 200,100,"test.inc"
This produces a mesh2, the begining of the file looks like this.
#declare Surface = mesh2 {
  vertex_vectors {
    20301
    <8.9916e-013,0.899161,0>....

If I select this file for input and select 'go', no problem.
If I select 'Optimize normal vectors with error tolerance 0.001'
and select 'go'
I get 'Optimizing...' this is taking a while so I go to do other things.
Select another program, POV-Ray.
Try to go back to Winmeshcomp, no responce.

Another observation:
Original file(20301 vertices, 40000 triangles)
test.inc 2 392 097 bytes

WinMeshcomp (no options selected)
meshcomp -y C:\Program Files\POV-Ray for Windows
v3.5\include\mesh_demo\test.inc C:\Program Files\POV-Ray for Windows
v3.5\include\mesh_demo\test.pcm
Found mesh with 40000 smooth triangles and 40602 points.
Done. ----
test.pcm 2 785 121 bytes ("PCM4",)
I didn't expect the file to be bigger.

Do these set of include files make an incompatible mesh2 object for
Winmeshcomp?

Stephen

Post a reply to this message

StephenS <ssh### [at] ottawanet> wrote:
> When the program is working on a large file(Optimizing), I can't go to
> another program (POV-Ray) and back to check if it's done. The WinMeshcomp
> window is unresponsive.

  That's normal because the program is calculating in a busy-loop and does
not listen to Windows' queries.
  I don't know how Windows programs are made "responsive" even while they
are making heavy calculations. I suppose that they have to make some
system call once in a while or something similar. Does anyone have a tip?

> test.inc 2 392 097 bytes
> test.pcm 2 785 121 bytes ("PCM4",)
> I didn't expect the file to be bigger.

  The mesh2 format is already pretty minimal. The only thing where pcm
could save is in additional syntax.
  The "PCM4" format is not completely identical to mesh2 and may in some
cases store more information than necessary. It depends a lot on what
the mesh2 contains.

-- 
plane{-x+y,-1pigment{bozo color_map{[0rgb x][1rgb x+y]}turbulence 1}}
sphere{0,2pigment{rgbt 1}interior{media{emission 1density{spherical
density_map{[0rgb 0][.5rgb<1,.5>][1rgb 1]}turbulence.9}}}scale
<1,1,3>hollow}text{ttf"timrom""Warp".1,0translate<-1,-.1,2>}//  - Warp -

Post a reply to this message

On 30 Jan 2004 05:05:18 -0500, Warp <war### [at] tagpovrayorg> wrote:

> StephenS <ssh### [at] ottawanet> wrote:
>> When the program is working on a large file(Optimizing), I can't go to
>> another program (POV-Ray) and back to check if it's done. The 
>> WinMeshcomp
>> window is unresponsive.
>
>   That's normal because the program is calculating in a busy-loop and 
> does
> not listen to Windows' queries.
>   I don't know how Windows programs are made "responsive" even while they
> are making heavy calculations. I suppose that they have to make some
> system call once in a while or something similar. Does anyone have a tip?

Multi-threading.
Launch a new thread for the calculations, and let the old one handle the 
GUI.

An alternative would be to do the calculations in small chunks (easy if 
there's a big loop involved) and do a message dispatch between chunks.

In my opinion, the MT approach is the preferred one. It's both cleaner and 
more robust.

Post a reply to this message