Finally, after so many years of laziness, I decided to enhance the
mesh compressor program to the POV-Ray 3.5 era. That is, it should
now have full support for mesh2's (reading and writing), as well
as uv-mapping in regular meshes.

  Chris Colefax is still working on the PCM macros and they are not
yet available, so you will only be able to test pov-pov and pov-pcm-pov
conversion. However, I think that most bugs should be possible to find
this way.

  Only Windows-version of the beta, sorry.
  (Oh dear, I would have never thought I would ever say something like
that, but... I'm not quite willing to publish the source before all the
most obvious bugs are fixed... Rest assured, however, that the
command-line version is extremely system-independent. :) )

  You can download the Windows beta version here:

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

  (In case you don't have the slightest idea what this is all about, see
http://www.geocities.com/ccolefax/pcm.html )

-- 
#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

Warp wrote:

>   Finally, after so many years of laziness, I decided to enhance the
> mesh compressor program to the POV-Ray 3.5 era. That is, it should


Yee hah!  Very cool indeed.

Post a reply to this message

"Warp" <war### [at] tagpovrayorg> wrote in message news:3fbd504e@news.povray.org...

>   Only Windows-version of the beta, sorry.

Excuses, excuses...

http://tinyurl.com/vykx

Post a reply to this message

On Fri, 21 Nov 2003 11:11:01 -0000, "Tom Melly" <tom### [at] tomandlucouk> wrote:

>
>http://tinyurl.com/vykx
>
LOL

Regards
        Stephen

Post a reply to this message

Tom Melly wrote:
> "Warp" <war### [at] tagpovrayorg> wrote in message news:3fbd504e@news.povray.org...
> 
> 
>>  Only Windows-version of the beta, sorry.
> 
> 
> Excuses, excuses...
> 
> http://tinyurl.com/vykx
> 
> 
> 
> 
Oh my goodness... that's hilarious. I want one.

--
Jonathan.

Post a reply to this message

Apparently the program is either completely bugless, or doesn't really
interest anyone...
  I hope it's the former. ;)

-- 
#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

Warp wrote:
>   Apparently the program is either completely bugless, or doesn't really
> interest anyone...
>   I hope it's the former. ;)
> 
It worked nicely as far as I was able to make use of it.  Unfortunately 
I think I need to have the color carry through for my application 
(hair).  So, so far I am just using the plain mesh.  But the mesh2 would 
give me more memory to work with so the jury is still out on which way I 
will comprimise as I increase the number of triangles.

I don't suppose .obj to pcm would be possible?

The thing is that Greg Johnson wrote some interesting macros adapting 
the pcm hair macros to give Maya options that might be interesting to 
try.  But any modelling I do is exported in .obj among others. 
Crossroads works just fine for this so it's hardly a big deal, but it 
would shorten the workflow.

-Jim

Post a reply to this message

Jim Charter <jrc### [at] msncom> wrote:
> I don't suppose .obj to pcm would be possible?

  Currently you will need to convert the .obj file to a mesh or mesh2
with some converter and then convert it to pcm with my program.

  I don't have the slightest idea what kind of format .obj is, but if
it's simple enough, I might add support for 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

Warp wrote:

> Jim Charter <jrc### [at] msncom> wrote:
> 
>>I don't suppose .obj to pcm would be possible?
> 
> 
>   Currently you will need to convert the .obj file to a mesh or mesh2
> with some converter and then convert it to pcm with my program. 
> 

I don't think so, you don't read Mesh2 just Mesh.  That is why the need 
for Crossroads.  It can read .obj and output Mesh.

>   I don't have the slightest idea what kind of format .obj is, but if
> it's simple enough, I might add support for it...
> 

I think it is originally a Alias/Wavefront format. I actually wondered 
if Mesh2 was modelled after .obj in part.  The prob with .obj is that it 
comes in a couple of flavors I think.  Something about different line 
endings, newline or carriage return.  Since I first tried mesh modelling 
in a Maya course it was the format I got used to and have confidence in. 
  But it is really a matter of which button to push. Personally I like 
to produce mesh models with Wings3D which exports in a number of formats.
Anyway, as I said there is a way to manage the situation.  Support for 
.obj or other commom mesh format would give your app more of a 
one-stop-shopping place in the workflow.  But the reward would have to 
come from the doing I expect.

Btw my present endeavor is trying to apply hair to a mesh such that the 
direction it lies in can be controlled more closely.  Have you ever 
applied youself to that problem?

Post a reply to this message

In article <3fd26413@news.povray.org>, Warp <war### [at] tagpovrayorg> 
wrote:

>   Currently you will need to convert the .obj file to a mesh or mesh2
> with some converter and then convert it to pcm with my program.
> 
>   I don't have the slightest idea what kind of format .obj is, but if
> it's simple enough, I might add support for it...

http://astronomy.swin.edu.au/~pbourke/geomformats/obj/
(more formats at http://astronomy.swin.edu.au/~pbourke/geomformats/)

http://pipin.tmd.ns.ac.yu/extra/fileformat/3d/index.htm

-- 
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

Jim Charter <jrc### [at] msncom> wrote:
> I don't think so, you don't read Mesh2 just Mesh.

  Then there's a serious bug in the program. I am able to read mesh2 (with
uv-mapping and textures) ok.
  Please make a proper bug report.

-- 
#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

Warp wrote:

> 
>   Then there's a serious bug in the program. I am able to read mesh2 (with
> uv-mapping and textures) ok.

Now I'm confused.

On the interface the selections for input include:

1. POV-Ray file with triangle meshes
2. POV-Ray file with cubic patches
3. PCM file

The selections for output include:

1. PCM file
2. POV-Ray file
3. UV-Pov mesh2

I did try selection #1 with "Ignore keywork mesh" checked
but got:
"no objects found"


>   Please make a proper bug report.
> 

Forgive me, I don't know how to do that

Post a reply to this message

Jim Charter <jrc### [at] msncom> wrote:
> Now I'm confused.

  Try reading the first post in this thread.

-- 
#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

Warp wrote:

> 
>   Try reading the first post in this thread.
> 

 >

Okay, a bit cryptic but I think I gotcha.

To be able to read it,
it matters which utility generates the mesh/mesh2.

Here is what I was able to test:

Can the mesh be read?

If generated by PoseRay v.0.1
Mesh - No
Mesh2 - No

If generated by CrossRoads v1
Mesh - Yes
Mesh2 - N/A

If generated by Win3D v4.3
Mesh - N/A
Mesh2 - No

If generated by MeshComp v3
Mesh - Yes
Mesh2 - Yes

If generated by POV-Ray v3.5
Mesh - Yes
Mesh2 - N/A


Not sure if it is a bug, but it means to me that
the only way I can get from a commercial format, such
as .obj, to PCM is via generating plain mesh in CrossRoads.

Post a reply to this message

Jim Charter <jrc### [at] msncom> wrote:
> If generated by PoseRay v.0.1
> Mesh2 - No

> If generated by Win3D v4.3
> Mesh2 - No

  Can you post a small example of those which the compressor can't read?

-- 
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

Warp wrote:

> Jim Charter <jrc### [at] msncom> wrote:
> 
>>If generated by PoseRay v.0.1
>>Mesh2 - No
> 
> 
>>If generated by Win3D v4.3
>>Mesh2 - No
> 
> 
>   Can you post a small example of those which the compressor can't read?
> 
In p.b.s-f

Post a reply to this message

Jim Charter <jrc### [at] msncom> wrote:
> In p.b.s-f

  This is exactly what I was looking for when I made the beta release.
There indeed is a bug in the program, and a rather simple one (or perhaps
more precisely a memory lapse): I forgot to make the parser to take
comments into account.
  For instance "mesh2 // comment" causes it to choke because it doesn't
skip the comment.
  I'll have to fix that.

-- 
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

I fixed the problem with comments. Please test it.

http://www.cs.tut.fi/~warp/WinMeshcomp30_beta2.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

Have you tried with the beta2 version of the program 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

Warp wrote:

>   Have you tried with the beta2 version of the program yet?
> 
Nothing too extensive.  I quickly ran it against about a dozen mesh2 
files I had laying around from both poseray and 3dwin4.  Largest was 
132572 triangles.  It worked fine.  Give me a day.  I investigated the 
"transforms" tab and I see that its functions could have some 
application for me too.  I also remember that povtree also generates 
some kind of mesh.  So I can try that too.  Maybe make a furry tree?

Post a reply to this message

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