[Ernesto]

To Next Limit Team:

Steps to reproduce the Bug:
Open a new scene
create a cube
Create a camera (aim)
Set Rendering settings to enable MOTION BLUR
Set the camera in the Maxwell Render tab, Uncheck EXPORT ANIMATION

And you will get all kind of weird things except an image of the cube.
Time invested finding the problem 6 hours.
Consequence, delayed deadline, and client unhappy.

Detailed explanation:

I use to render stills and ocassionally animation. Use Maya 2012 and maxwell 2.7
When rendering stills I do not need to set up an animation. When rendering animations I have no problems either.

But when I need to render an image with motion blur, I have to setup an animation , to render a still.
In such particular case I have found a very strange bug, I do not know if this is in maxwell or in the Maya Pluggin.
Here I will describe in detail:

The file was set for an animation of 600 frames, but is intended to be used for a still image.
By default the cameras are set to EXPORT ANIMATION, (camera settings/Maxwell/Export animation) but in this particular case I wanted a still, so I unchecked the box. What I had after unchecking the box were one of the following in no particular order, but randomly:

1) a black image (impossible to adjust with the exposure settings, it is black no matter the settings)
2) an almost black image with light shapes blurry and I can see that they are my lights because they are sensitive to the Multilights settings.
3) a blurry image as if the focus would be set at 10 cm
4) a totally blocked image. I see a gray plane that can be adjusted with the exposure, changing it to while or black but no detail at all, as if there would be a plane in front of the camera.
5) an image belonging to the perspective camera. I made sure that the current active camera is the one i want, but as soon as I try to render it it shows me the persp camera instead.
6) Sometimes it shows another camera, but I noticed that it do not show the film offset as this other camera was set. I made sure it was not the perspective camera, it was a second camera, but although it is set with an offset of 0.4, in this weird image it shows it as if the offset value would be 0.

I must say that all the cameras are still and are not animated at all.

One more thing: all these bugs happens when MOTION BLUR is activated in the Rendering Settings.
As soon as motion blur is disabled everything works OK again.
So It seems that two things are needed to reproduce the BUG:
1) Motion Blur enabled
2) Uncheck EXPORT ANIMATION inside camera settings.

Finnally when i discovered that checking the EXPORT ANIMATION again, everything gets normal.
Just to be sure I tried to export to MXS file, and in the exporting window the ANIMATION was unchecked.

This disoriented me a bit since I thought that the box inside the camera that says EXPORT ANIMATION, was the same as the ANIMATION box in the exporting MXS file windows, but it seems it is not.

So I wonder about the use of the EXPORT ANIMATION box inside the camera settings/Maxwell, that is so dangerous.

Ernesto

[Mihnea Balta]

There is indeed a bug with the motion export flag which will be fixed in the next build, but you don't need to use it. That checkbox should simply turn off blur from the camera motion, in case the camera is animated. When there's no camera animation, it won't have any effect (after the bug is fixed).

[Ernesto]

Thanks Mihnea Balta,

It seems that you knew already about this....
This discourages me of taking the time to explore the bug, and report it the next time!
Also it turns my trouble unnecesary. That is the reason I am asking Next Limit an official Bug List, where you can diferenciate the fixed from the unfixed, but already known. This is a common practice in software development, and help saving valuable time of the users and developpers. The first would have the necesary information to avoid known problems. In case finding one, we could check if this is in the list or not. In case it is already in the list, we will save also valuable time reporting a problem that is already known. The second would save time explaining one by one that this was a known bug that is going to be fixed in nex version. Would you pleasse do it?
Pleasse!

Ernesto

[Mihnea Balta]

We didn't know about the bug. I've identified and fixed it today, after you reported it.

Most of the issues are reported by users on the forums. We also get a few reports through the customer portal and directly by e-mail, but not that many. As it stands now, a bug page would pretty much be a mirror of this subforum, so you wouldn't get much out of it.

[Ernesto]

I insist.
I do not mean a bug page, you need a file only.
When a new version of a software is released it is distributed along with a file, that says what was changed.
In that same file the solved bugs are listed, as well as the waiting to be solved bugs.
It is about being respectfull with users.
Otherwise I have told you the bad consequences for users and for developpers.
On the other hand what should be the advantage of hiding the information?
If somebody in Next Limit thinks that showing the bug list is not a good publicity, I can tell you that it is the oposite.
Credibility is increased with transparency policy, and secretism demolish credibility.
You should do it for the benefit of all:
Users, Developers and Company credibility.

Ernesto

[Mihnea Balta]

Are you seriously saying we don't publish release notes, or are you just trolling me at this point? There's a sticky thread at the top of this subforum: http://www.maxwellrender.com/forum/view ... 2&start=15. There's a page in the documentation about it: http://support.nextlimit.com/display/ma ... on+history. There's a link in the update dialog that opens the release notes (it points here: http://www.maxwellrender.com/qetuombcza ... es_2.0.txt). Have you ever seen these? Have you noticed the lines starting with "fixed"? Those are the bugs which were fixed in each release.

We almost never release plug-in builds with known bugs. We gather reports from users and fix all of them before releasing a new build. When there are known issues, we list them in the release notes. There were no known plug-in issues when we released 2.7.20. I didn't know that checkbox was broken. A list of known issues wouldn't have helped you, because this wasn't a known issue. Am I sufficiently clear?

Please tone it down a notch. We're not hiding anything from you, we're not delaying fixes intentionally to get you to pay for upgrades (as you suggested in another thread), we're not avoiding issues to make us look good, we're as transparent as possible (and much more transparent than other companies in this field). Nobody else is complaining about these things. The problem is on your end.

I can't be respectful if you're being absurd. I'm respectful and reasonable, but you're not seeing it, because you like blowing everything out of proportion and fixating for 6 hours on a checkbox you didn't need to use in the first place.

Now can we please get back to work, or would you like to fantasize some more about known issues, missing release notes, lack of transparency and the Next Limit conspiracy to get you to miss your deadlines by luring you with broken checkboxes?