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

On Fri, 03 Sep 2004 11:01:58 -0400, Jim Charter <jrc### [at] msncom> wrote:
> > >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 think you are trying to think too seriously about sentence marked with a
smile. Hovewer if you really want to find an answer here I can say for myself
that it is not problem with "bug reporting" but "bug" definition. If the
binary delivered would create wrong output according to given script than this
is a bug. But if the output is correct but generated slowly than perhaps it is
slow io operations or poor compiler or not optimized algorithm but still
usable tool. I well understand it is not comfortable using such slow tool but
while I'm interested in listening any impressions from using MegaPOV, memory
leaks, broken pixels or security issues have highier priority in solving than
slow execution (thought we are still interested in such observations once we
release final MegaPOV 1.1 and will try to solve everything we are able to find
and fix). Sorry I can't define my understanding of "bug" any better due to
limited english. Perhaps I even use wrong word for expressing so I can only
sorry if I fail to meet your (seems native speaker) understanding :-(

Thanks for any feedback received from anyone during whole past beta existence.
Perhaps not everything was answered but all issues were at least investigated
and considered by the MegaPOV developers. I had a very limited free time in
past days but other MegaPOV fellows did a very good work on moving things
forward.

> I worked as a programmer, and in quality 
> assurance, for fifteen years

Welcome to the club. We are not young boys too ;-)

ABX

Post a reply to this message

ABX wrote:

> 
> I think you are trying to think too seriously about sentence marked with a
> smile. 

I took the smile as an invitation to discuss the problem further :)


Hovewer if you really want to find an answer here I can say for myself
> that it is not problem with "bug reporting" but "bug" definition. 

Okay, I see.  And in classic full project life cycle those definitions 
and their test beds would derive from the original user specifications, 
which obviously are not existent in this case.  Any system must 
prioritize for testing purposes. Is speed the emphasis? Usability? 
System integrity?  Or a reasonable balance?  Yes, now I understand the 
problem better.

If the
> binary delivered would create wrong output according to given script than this
> is a bug. But if the output is correct but generated slowly than perhaps it is
> slow io operations or poor compiler or not optimized algorithm but still
> usable tool. I well understand it is not comfortable using such slow tool but
> while I'm interested in listening any impressions from using MegaPOV, memory
> leaks, broken pixels or security issues have highier priority in solving than
> slow execution (thought we are still interested in such observations once we
> release final MegaPOV 1.1 and will try to solve everything we are able to find
> and fix). Sorry I can't define my understanding of "bug" any better due to
> limited english. Perhaps I even use wrong word for expressing so I can only
> sorry if I fail to meet your (seems native speaker) understanding :-(

I think in this case what was reported was the possibility that previous 
speed marks had been degraded in subsequent versions.  Without knowing 
that you consider this to be a reasonable compromise for other 
improvements, I can understand that someone might think they'd found 
something faulty.

> 
> Thanks for any feedback received from anyone during whole past beta existence.
> Perhaps not everything was answered but all issues were at least investigated
> and considered by the MegaPOV developers. I had a very limited free time in
> past days but other MegaPOV fellows did a very good work on moving things
> forward.
> 
> 
Well you would be welcome but I must concede that I don't report 
anything I come across because I don't relish having the "not a proper 
bug report" line thrown in my face.

Post a reply to this message