 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
i've run a few tests with simple objects and everything works fine.
then i try to scan the complex object i was talking about in my previous
post and megapov closes on me with no explaination! i barely starts to
parse, and then blamo! it blows up! how do i fix this?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
ryan constantine wrote:
>
> i've run a few tests with simple objects and everything works fine.
> then i try to scan the complex object i was talking about in my previous
> post and megapov closes on me with no explaination! i barely starts to
> parse, and then blamo! it blows up! how do i fix this?
What precisely are you trying to scan? Is it, or does it contain
a triangle mesh, perchance? I did run into a problem while developing
triscan that MegaPOV 0.4 went boom when the trace() function was used
against a mesh{...} object. Same deal with mesh2{...} The only way
around it was to change mesh{...} to union{...} (which you can
still see in the routines which export the culling.tmp file)
It's not an ideal solution, since the mesh primitive has memory
advantages, but for the nonce, it's a workaround.
I reported the problem, but, as I recall, I was too late, and
there was an acknowledgement that someone else already reported
that, and that it is supposed to be fixed in the next release
of MegaPOV.
The only other thing that ever crashed MegaPOV entirely without
error message was running a scene with no objects in it, but I
added the generic Triscan_Setup() submacro to cure that by adding
a simple camera and text object, so that shouldn't be it anymore.
Let me know if any of this helps. If not, can you make the
troublesome target object available, and we'll see if I can
confirm it so I can make a deeper inquiry into it.
Charles
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Almost all objects are solids, but i do have about six bezier patch cylinders
and one moray plugin dome, which is smooth and small. Are these what you're
talking about? If so, how do i make those a union? Is all i do change the
'dome' to 'union'? would it help if you could see the code of the pov file?
It's "only" about 4000+ lines long so far. If i can't easily work this out,
i'll just forget about making the distributed files (when i'm done) easily
read and just make a good readme file so people can use this model. That
might be best anyway.
Charles Fusner wrote:
> ryan constantine wrote:
> >
> > i've run a few tests with simple objects and everything works fine.
> > then i try to scan the complex object i was talking about in my previous
> > post and megapov closes on me with no explaination! i barely starts to
> > parse, and then blamo! it blows up! how do i fix this?
>
> What precisely are you trying to scan? Is it, or does it contain
> a triangle mesh, perchance? I did run into a problem while developing
> triscan that MegaPOV 0.4 went boom when the trace() function was used
> against a mesh{...} object. Same deal with mesh2{...} The only way
> around it was to change mesh{...} to union{...} (which you can
> still see in the routines which export the culling.tmp file)
> It's not an ideal solution, since the mesh primitive has memory
> advantages, but for the nonce, it's a workaround.
>
> I reported the problem, but, as I recall, I was too late, and
> there was an acknowledgement that someone else already reported
> that, and that it is supposed to be fixed in the next release
> of MegaPOV.
>
> The only other thing that ever crashed MegaPOV entirely without
> error message was running a scene with no objects in it, but I
> added the generic Triscan_Setup() submacro to cure that by adding
> a simple camera and text object, so that shouldn't be it anymore.
> Let me know if any of this helps. If not, can you make the
> troublesome target object available, and we'll see if I can
> confirm it so I can make a deeper inquiry into it.
>
> Charles
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Of course you do what you want but I don't understand something:
If your object is created with Moray (as the dome) why do you need to
get an approximate representation with triscan?? You already have this
representation in Moray and it is better than with triscan. If this
is to have a smaller mdl I don't understand because mdl are smaller
than inc.
Fabian.
>
> Almost all objects are solids, but i do have about six bezier patch cylinders
> and one moray plugin dome, which is smooth and small. Are these what you're
> talking about? If so, how do i make those a union? Is all i do change the
> 'dome' to 'union'? would it help if you could see the code of the pov file?
> It's "only" about 4000+ lines long so far. If i can't easily work this out,
> i'll just forget about making the distributed files (when i'm done) easily
> read and just make a good readme file so people can use this model. That
> might be best anyway.
>
> Charles Fusner wrote:
>
> > ryan constantine wrote:
> > >
> > > i've run a few tests with simple objects and everything works fine.
> > > then i try to scan the complex object i was talking about in my previous
> > > post and megapov closes on me with no explaination! i barely starts to
> > > parse, and then blamo! it blows up! how do i fix this?
> >
> > What precisely are you trying to scan? Is it, or does it contain
> > a triangle mesh, perchance? I did run into a problem while developing
> > triscan that MegaPOV 0.4 went boom when the trace() function was used
> > against a mesh{...} object. Same deal with mesh2{...} The only way
> > around it was to change mesh{...} to union{...} (which you can
> > still see in the routines which export the culling.tmp file)
> > It's not an ideal solution, since the mesh primitive has memory
> > advantages, but for the nonce, it's a workaround.
> >
> > I reported the problem, but, as I recall, I was too late, and
> > there was an acknowledgement that someone else already reported
> > that, and that it is supposed to be fixed in the next release
> > of MegaPOV.
> >
> > The only other thing that ever crashed MegaPOV entirely without
> > error message was running a scene with no objects in it, but I
> > added the generic Triscan_Setup() submacro to cure that by adding
> > a simple camera and text object, so that shouldn't be it anymore.
> > Let me know if any of this helps. If not, can you make the
> > troublesome target object available, and we'll see if I can
> > confirm it so I can make a deeper inquiry into it.
> >
> > Charles
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
ryan constantine wrote:
>
> Almost all objects are solids, but i do have about six bezier patch cylinders
> and one moray plugin dome, which is smooth and small. Are these what you're
> talking about? If so, how do i make those a union? Is all i do change the
> 'dome' to 'union'? would it help if you could see the code of the pov file?
> It's "only" about 4000+ lines long so far. If i can't easily work this out,
> i'll just forget about making the distributed files (when i'm done) easily
> read and just make a good readme file so people can use this model. That
> might be best anyway.
Well, I've checked it with bezier patches, and they don't cause a
crash, but I have to admit I haven't tried the dome plugin yet. (I
wanted to research it more before I wrote this, but my ISP is
having intermittant service outages and I don't even know when I'll
be able to send this) If the plugin does what it does with
triangle meshes (which is possible), that may be causing the problem.
Try a single dome object all by itself, and see if that still
crashes. If so, what you're going to have to do is find whatever
include file the dome object is exported to, and open it in the POV
editor. It should contain references to the mesh {... } primitive
By replacing all occurences of the word "mesh" with "union" you'll
get exactly the same object geometry, only without the memory
advantages of a mesh object. HOWEVER, it should triscan normally.
You can always replace the unions with meshes again when you've
got the scan you needed.
Charles
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Fabian BRAU wrote:
>
> Of course you do what you want but I don't understand something:
> If your object is created with Moray (as the dome) why do you need to
> get an approximate representation with triscan?? You already have this
> representation in Moray and it is better than with triscan. If this
> is to have a smaller mdl I don't understand because mdl are smaller
> than inc.
Hmm.. good point, usually, but there's two case I can think of:
#1. If you had a REALLY big model (say several hundred pieces)
and a fairly slow machine, Moray gets really slow when your
total scene starts to have several thousand objects (which
I've done) Sometimes you can make a low res UDO to stand in
for several hundred pieces and replace several hundred
objects with 1 UDO object, making Moray move somewhat
quicker.
#2. You might want to turn the Moray object into a prop for
Poser, or a reference object for Leveller or something.
(since it's a dome object, this sounds likely). This in
fact was one of my own intended uses for triscan when I
wrote it. :)
Charles
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Charles Fusner wrote:
> but I have to admit I haven't tried the dome plugin yet. (I
> wanted to research it more before I wrote this, but my ISP is
> having intermittant service outages and I don't even know when I'll
> be able to send this) If the plugin does what it does with
> triangle meshes (which is possible),
Okay, --- FINALLY! --- I have normal internet access back (took
them long enough) so I downloaded the dome generator, and tested
with a randomly generated dome. They DO have triangle meshes in
them... although they are not altogether a mesh like I expected.
Apparently anything the plugin can do with non-meshes, it does,
but sometimes, you'll have a mesh{...} object in the dome union,
so that's most probably the cause of the triscan crash. Open
your .pov file in a text editor, and do a text search for all
occurances of the keyword "mesh", replacing it with "union" and
you should be able to scan it.
Hmmm... very interesting plugin, too.
Charles
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
What is triscan? if this has been covered elswhere, please point the way.
thanks
Steven
Charles Fusner <cfu### [at] enter net> wrote in message
news:38DFF17A.89AD9C6A@enter.net...
> Charles Fusner wrote:
> > but I have to admit I haven't tried the dome plugin yet. (I
> > wanted to research it more before I wrote this, but my ISP is
> > having intermittant service outages and I don't even know when I'll
> > be able to send this) If the plugin does what it does with
> > triangle meshes (which is possible),
>
> Okay, --- FINALLY! --- I have normal internet access back (took
> them long enough) so I downloaded the dome generator, and tested
> with a randomly generated dome. They DO have triangle meshes in
> them... although they are not altogether a mesh like I expected.
> Apparently anything the plugin can do with non-meshes, it does,
> but sometimes, you'll have a mesh{...} object in the dome union,
> so that's most probably the cause of the triscan crash. Open
> your .pov file in a text editor, and do a text search for all
> occurances of the keyword "mesh", replacing it with "union" and
> you should be able to scan it.
>
> Hmmm... very interesting plugin, too.
>
> Charles
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Steven Durham wrote:
>
> What is triscan? if this has been covered elswhere, please point the way.
> thanks
http://www.enter.net/~cfusner/tutorial/ch25.html
--
Ken Tyler - 1300+ Povray, Graphics, 3D Rendering, and Raytracing Links:
http://home.pacbell.net/tylereng/index.html http://www.povray.org/links/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
