Oh - a quick note. Win98 seems to have all the runtime stuff for VB5
already. So if you're using Win98 then all you need is the ~100K .ZIP file
and perhaps the documentation (there's a link to an online copy of that).

Win2000 may well have the runtime too. Worth a try, at least (although since
there's only the .exe in the update file, you'll have to select a location
on your hard drive to store it, and possibly create a shortcut to the dektop
and/or start menu yourself).


--
Cheers,
Cliff Bowman

http://www.geocities.com/who3d/

Post a reply to this message

Cliff Bowman wrote:
> 
> >
> > I often use OBJuvPOV in conjonction with UVMapper, and it works
> > perfectly for me
> > (except that the camera and light location are generated with ','
> > instead of '.'
> > in the numbers (am I clear ??)...)
> >
> 
> Possibly. It attempts to calculate reasonable light and camera positions
> based on the model. so, for example, for the Poser4 lo-resolution casual
> female (with no hair) exported as box.obj (for reasons too silly to go into)
> it produces the following .POV file (but without the annotations which I've
> added manually).

What I was talking about is the separator used between the int part and
decimal part of the floats int camera locations. On a french system,
this separator is a ',', not a '.'. I think that VB use the default
separator of the system to print floats, so my camera declaration was
somethong like that:

camera {
 location < 0,32145, 0,7521, -0,4582> // 5 ',' in a vector, POV doesn't
like that :)
 look_at < 0,32145, 0,7521, -0,00321>
}

and the same for light source locations....


For all the rest, it's a great program, and works almost perfectly. I
had a problem, once, with a mesh without normals, it generated a bad
mesh2, but using a conversion program to add normal information was the
solution....
So far, I've used OBJuvPOV to convert OBJ mesh that comes from various
3D software (Lightwave esentially, after conversion in OBJ), but last
night, I've converted my first real Poser OBJ file, and all was OK, so,
one more time: IT'S A GREAT PROG !!!!

I'll get the zip without VB runtime, and I'll try this tonight.

Thanks a lot.

Bouf.

Post a reply to this message

"Christophe Bouffartigue" <Chr### [at] nanterremarellifr>
wrote in message news:39A3796C.3E6CE5A5@nanterre.marelli.fr...
> Cliff Bowman wrote:
> >
> > >
> > > I often use OBJuvPOV in conjonction with UVMapper, and it works
> > > perfectly for me
> > > (except that the camera and light location are generated with ','
> > > instead of '.'
> > > in the numbers (am I clear ??)...)
> > >
> >
> > Possibly. It attempts to calculate reasonable light and camera positions
> > based on the model. so, for example, for the Poser4 lo-resolution casual
> > female (with no hair) exported as box.obj (for reasons too silly to go
into)
> > it produces the following .POV file (but without the annotations which
I've
> > added manually).
>
> What I was talking about is the separator used between the int part and
> decimal part of the floats int camera locations. On a french system,
> this separator is a ',', not a '.'. I think that VB use the default
> separator of the system to print floats, so my camera declaration was
> somethong like that:
>
> camera {
>  location < 0,32145, 0,7521, -0,4582> // 5 ',' in a vector, POV doesn't
> like that :)
>  look_at < 0,32145, 0,7521, -0,00321>
> }
>
> and the same for light source locations....
>

Doh! Sudden dawning <light bulb flashes on and as in a like a cheap SF
program>

Hmmm... Do you think it's worth my addressing, or is it easy enough to
change the .POV files? For that matter - how well are the meshes coming out?
If they're getting some "," characters instead of "." characters I cans see
that messing up big time (potentially, at least). I hadn't even though about
countries not using "." as the decimal place operator (though more and more
I see figures presented that way on paper - annoys the biggins out of me).
The "completely new lots of wonderful new features written all in C++"
version (OBJuvMOD) is still a *long* way away even if I get it to do
everything I want (for example, adding normals to .OBJ meshes without
normals, editing normals semi-visually so that meshes with normal errors can
be corrected, possibly other features that I'd *like* to do, like UV Map
co-ordinate editing) so don't be expecting the new program to replace
OBJuvPOV this side of Christmas (at least). I expect my health to be good
enough to return to work soon (with luck) so I'll have even less time for
development work too :(

>
> For all the rest, it's a great program, and works almost perfectly. I
> had a problem, once, with a mesh without normals, it generated a bad
> mesh2, but using a conversion program to add normal information was the
> solution....
> So far, I've used OBJuvPOV to convert OBJ mesh that comes from various
> 3D software (Lightwave esentially, after conversion in OBJ), but last
> night, I've converted my first real Poser OBJ file, and all was OK, so,
> one more time: IT'S A GREAT PROG !!!!
>

It's a simple hack knocked up by someone who needed it himself. Given all
I've had out of the POV-Ray community (by way of scene source, helpful
comments etc.) I'd be a bit rude not to offer it around. IMO :)

The next effort will, I hope, be much more worthy of the accolade "program"
and less prone to the term "hack". But we'll see...


--
Cheers,
Cliff Bowman

http://www.geocities.com/who3d/

Post a reply to this message

Cliff Bowman wrote:
> 
> 
> Doh! Sudden dawning <light bulb flashes on and as in a like a cheap SF
> program>

beautiful metaphor... ;)

> Hmmm... Do you think it's worth my addressing, or is it easy enough to
> change the .POV files?

It is easy enough to change (but surprising the first time...). Maybe
you can point it in some docs... So I can wait for your OBJuvMOD....
OBJuvPOV have all the fonctionalities I need for the moment...

> For that matter - how well are the meshes coming out?

The meshes are OK (if I understand right your question...).


> OBJuvPOV this side of Christmas (at least). I expect my health to be good
> enough to return to work soon (with luck) so I'll have even less time for
> development work too :(

I's better worth to have a good health instead of plenty of time for
development. Believe me... Hope you'll be better...

Bouf.

Post a reply to this message

"Christophe Bouffartigue" <Chr### [at] nanterremarellifr>
wrote in message news:39A3AA77.670E16BC@nanterre.marelli.fr...
> Cliff Bowman wrote:
> >
> >
> > Doh! Sudden dawning <light bulb flashes on and [Ed - and off] as in a
cheap SF
> > program>
>
> beautiful metaphor... ;)

I'm a Doctor Who fan (as if you couldn't guess) and also a fan of Terry
Pratchett. SF and humour are both things I appreciate :)

> > Hmmm... Do you think it's worth my addressing, or is it easy enough to
> > change the .POV files?
>
> It is easy enough to change (but surprising the first time...). Maybe
> you can point it in some docs... So I can wait for your OBJuvMOD....
> OBJuvPOV have all the fonctionalities I need for the moment...
>
> > For that matter - how well are the meshes coming out?
>
> The meshes are OK (if I understand right your question...).
>

You do indeed - and I'm afraid I was a little impatient. Once I knew what
the problem was, I had a quick glance at the code to see if I could easily
do anything about it (it may be a small problem, but I hate software that
I've written that has niggly "issues" even more than I hate having to deal
with other people's "niggly" software). So I've produced a possible fix for
the comma/decimal point problem. I'd be most appreciative if you could test
it and let me know how this new version (0.0.13!) performs.

<looks to the newsgroup name> Hmmm... I ought to be able to attach the "no
libraries" version here easily enough...

>
> > OBJuvPOV this side of Christmas (at least). I expect my health to be
good
> > enough to return to work soon (with luck) so I'll have even less time
for
> > development work too :(
>
> I's better worth to have a good health instead of plenty of time for
> development. Believe me... Hope you'll be better...
>

Absolutely. I may even be able to *buy* stuff that at the moment I write or
do without instead! (looking forward to getting back to work).

Pls let me know if this new version is an improvement - if it is I'll update
the history documentation and upload it to the web site.


--
Cheers,
Cliff Bowman

http://www.geocities.com/who3d/

Post a reply to this message

Attachments:
Download 'OUP0013.zip' (92 KB)

Cliff Bowman wrote:
> 
> 
> I'm a Doctor Who fan (as if you couldn't guess) and also a fan of Terry
> Pratchett. SF and humour are both things I appreciate :)

Waoh, I'm a TPratchett fan too. But I only read the french translations
:(


> with other people's "niggly" software). So I've produced a possible fix for
> the comma/decimal point problem. I'd be most appreciative if you could test
> it and let me know how this new version (0.0.13!) performs.

Nop !! Not OK. There's always tge problem with camera and light sources,
but now, also with the OBJuvPOVmaxX variable...

If you can't find a quick fix to it, then don't bother. I'll continue to
use your soft "as is"... The "#version" evolution is already a good
thing, I dont' need anymore to modify the inc file...

Thanks for all.

Bouf.

Post a reply to this message

"Christophe Bouffartigue" <Chr### [at] nanterremarellifr>
wrote in message news:39A4DEE1.3165AFB0@nanterre.marelli.fr...
> Cliff Bowman wrote:
> >
> >
> > I'm a Doctor Who fan (as if you couldn't guess) and also a fan of Terry
> > Pratchett. SF and humour are both things I appreciate :)
>
> Waoh, I'm a TPratchett fan too. But I only read the french translations
> :(
>

I'll try not to let slip what happens in "The Truth" then :)

>
> > with other people's "niggly" software). So I've produced a possible fix
for
> > the comma/decimal point problem. I'd be most appreciative if you could
test
> > it and let me know how this new version (0.0.13!) performs.
>
> Nop !! Not OK. There's always tge problem with camera and light sources,
> but now, also with the OBJuvPOVmaxX variable...

Darn - OK, I've spotted my flaw (which was to let other people do the
testing rather than reproduce the fault myself and then work on it. Bad me).
While I was tidying up I've also made the #version less of a hack (it now
only includes the line if you've selected one of the MegaPOV formats to
export to) and made mesh and trimap exports use the same technique (they'd
have failed in France too!). Curiously MegaPOV 0.5A seems to parse even the
Trimap version faster than the official 3.1g does - and unlike 3.1g you can
place multiple copies of a single UV mesh (Trimap, mesh, or mesh2) object in
a scene without the UV mapping going haywire. I guess that means it's a
problem with 3.1g...

...still, even with the official 3.1g you can load a UV-mapped mesh and
translate it around the scene (oh - I didn't try scaling it, I only tried
rotating and translating it) thanks to Chris Colefax's Trimap macro. Cool.

> If you can't find a quick fix to it, then don't bother. I'll continue to
> use your soft "as is"... The "#version" evolution is already a good
> thing, I dont' need anymore to modify the inc file...
>

God that must have been a pain! Especially if you're using large meshes.
People really should, IMO, complain more often. I hope this is the best
version you've seen, I plan to update the documentation and the web site,
oh, "sometime soon now" (probably sometime in the next few days).


--
Cheers,
Cliff Bowman

http://www.geocities.com/who3d/

Post a reply to this message

Attachments:
Download 'OUP0014.zip' (94 KB)

Cliff Bowman wrote:
> 

> People really should, IMO, complain more often. I hope this is the best
> version you've seen, I plan to update the documentation and the web site,
> oh, "sometime soon now" (probably sometime in the next few days).

Bingo !!! That's it !!! I keep this one.  :))

Thanks a lot.

And now, let's render (probably some discworld related pictures.... I
hope).

Bouf.

Post a reply to this message