Hi there,

I'm building a *.lua-plugin for basic cloth-support in Moray. While 
fidlling around i noticed that a scene that took 16 secs parsing 
(cloth-creating) in mPov1.0 now takes 3.5 minutes. Could someone explain 
me why?

Arne

Post a reply to this message

Arne Kleinophorst wrote:
> Hi there,
> 
> I'm building a *.lua-plugin for basic cloth-support in Moray. While 
> fidlling around i noticed that a scene that took 16 secs parsing 
> (cloth-creating) in mPov1.0 now takes 3.5 minutes. Could someone explain 
> me why?

The information you gave is of course completely insufficient to answer 
this but since i assume you use the Windows version you could try the 
alternative compile offered on the MegaPOV website.

Christoph

-- 
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 06 Jul. 2004 _____./\/^>_*_<^\/\.______

Post a reply to this message

Yes, sorry, i was talking about the windows version.

But you can easily check it out:

Take the nappe.pov, change version to megapov 1.0 and render it with 1.0 
and 1.1
It's an enormous difference, and switching to the other windows version 
was not changing anything.
Hope that helps more.

Arne

Christoph Hormann schrieb:
> Arne Kleinophorst wrote:
> 
>> Hi there,
>>
>> I'm building a *.lua-plugin for basic cloth-support in Moray. While 
>> fidlling around i noticed that a scene that took 16 secs parsing 
>> (cloth-creating) in mPov1.0 now takes 3.5 minutes. Could someone 
>> explain me why?
> 
> 
> The information you gave is of course completely insufficient to answer 
> this but since i assume you use the Windows version you could try the 
> alternative compile offered on the MegaPOV website.
> 
> Christoph
>

Post a reply to this message

Arne Kleinophorst wrote:
> Yes, sorry, i was talking about the windows version.
> 
> But you can easily check it out:
> 
> [...]

There is nothing we need to check out.  We are completely aware of the 
fact that the executable in the Windows beta package is quite slow. 
That's why we provided the alternative version.

Christoph

-- 
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 06 Jul. 2004 _____./\/^>_*_<^\/\.______

Post a reply to this message

Nice support!

But if you would have read on you would have noticed that the 
alternative version is also not faster. And i just don't see why a 
feature which apparently has not changed is sooo much slower now.

I thought i provided some kind of bug report but this does not seem to 
be wanted.

Arne


Christoph Hormann schrieb:
> Arne Kleinophorst wrote:
> 
>> Yes, sorry, i was talking about the windows version.
>>
>> But you can easily check it out:
>>
>> [...]
> 
> 
> There is nothing we need to check out.  We are completely aware of the 
> fact that the executable in the Windows beta package is quite slow. 
> That's why we provided the alternative version.
> 
> Christoph
>

Post a reply to this message

Arne Kleinophorst wrote:
> Nice support!
> 
> But if you would have read on you would have noticed that the 
> alternative version is also not faster. And i just don't see why a 
> feature which apparently has not changed is sooo much slower now.
> 
> I thought i provided some kind of bug report but this does not seem to 
> be wanted.

This wasn't a bug report, first of all because it is not a bug but a 
perfectly natural and known behaviour of the program.  There is nothing 
wrong with the cloth simulation patch and the Linux beta version of MP 
1.1 renders nappe.pov even faster than MP 1.0.  Apart from that it of 
course lacked most of the requirements of a bug report.

And to be perfectly honest - if you find the program too slow just don't 
use it.  We are trying hard to provide a working Windows GUI version 
although this is really far from trivial.  So if you think you can do 
better just do so.  It is completely understandable that the low speed 
of the executable is frustrating for the users but instead of 
complaining it would be more productive to actually try doing something 
against it.

Christoph

-- 
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 06 Jul. 2004 _____./\/^>_*_<^\/\.______

Post a reply to this message

On Fri, 03 Sep 2004 11:44:42 +0200, Arne Kleinophorst
<kle### [at] spamdebitelnet> wrote:
> But if you would have read on you would have noticed that the 
> alternative version is also not faster. And i just don't see why a 
> feature which apparently has not changed is sooo much slower now.

The feature is only part of whole package. MegaPOV 1.0 was based on POV-Ray
3.5, MegaPOV 1.1 beta is based on POV-Ray 3.6.1. That was many times mentioned
that 3.5 and 3.6 differs a lot but internally: various C++ support,
frontend/backend architecture, new compilers, various bugfixes. That's
possible that in case of Windows port some of internal changes affected Cloth
patch as well in the way we failed to notice. We are working hard on MegaPOV
1.1 final relase and we are open to your observations and suggestions once the
new binaries and sources are released.

> I thought i provided some kind of bug report...

I would call it an 'impression' :-)

ABX

Post a reply to this message

ABX wrote:

> On Fri, 03 Sep 2004 11:44:42 +0200, Arne Kleinophorst
> <kle### [at] spamdebitelnet> wrote:
> 
>>But if you would have read on you would have noticed that the 
>>alternative version is also not faster. And i just don't see why a 
>>feature which apparently has not changed is sooo much slower now.
> 
> 
> The feature is only part of whole package. MegaPOV 1.0 was based on POV-Ray
> 3.5, MegaPOV 1.1 beta is based on POV-Ray 3.6.1. That was many times mentioned
> that 3.5 and 3.6 differs a lot but internally: various C++ support,
> frontend/backend architecture, new compilers, various bugfixes. That's
> possible that in case of Windows port some of internal changes affected Cloth
> patch as well in the way we failed to notice. We are working hard on MegaPOV
> 1.1 final relase and we are open to your observations and suggestions once the
> new binaries and sources are released.
> 
> 
>>I thought i provided some kind of bug report...
> 
> 
> I would call it an 'impression' :-)
> 
> ABX
Perhaps there could be a more public treatment on these groups of what 
is correct bug reporting.  I worked as a programmer, and in quality 
assurance, for fifteen years, in very large, and fairly well-organized, 
IT shops, yet I have little idea what you guys mean by "bug report"  To 
be quite honest it seems like it is a term hurled at posters to impune 
their abilities, or qualifications, in some none specific way.  I 
understand that you might want to extract a certain formality from bug 
reporters to establish their good faith, and make the report useful. 
But also, that this might be balanced against a need to collect evidence 
of faulty behavior.  But maybe not.  Could we use the ng to promote more 
awareness of all sides of this problem?

-Jim

Post a reply to this message

Jim Charter wrote:
> 
> Perhaps there could be a more public treatment on these
> groups of what is correct bug reporting.

This can be found in p.a.frequently-asked-questions.

  -Shay

Post a reply to this message

Shay wrote:
> Jim Charter wrote:
> 
>>
>> Perhaps there could be a more public treatment on these
>> groups of what is correct bug reporting.
> 
> 
> This can be found in p.a.frequently-asked-questions.
> 
>  -Shay
It doesn't seem to develop much awareness there.

Post a reply to this message