Maxwell Render | Official public forum

Another Studio bug.

MATERIAL EDITOR File tab Textures List lists textures that are not used in any material (they were used in the past) showing up as double, file paths that no longer exist and a texture supposedly not loaded although it is not used in any MXM (we checked very carefully).

This is interesting and would explain why I get a load of missing texture errors almost every time when uploading to RebusFarm to render... Having "legacy" textures referenced means every file is required/uploaded along with the project. As a lot of my materials are updated from older versions rather than started from scratch, I have been scratching my head as to why a texture is needed that is not actually being used anymore!

I should point out that the Rebus software does now have an option to replace missing files with dummy versions...

Another Studio bug.

When connected to the internet (WLAN or ethernet cable), opening and saving files and textures, starting FIRE and changing even a single setting on a MaxwellScatter modifier takes up to half a minute. Much network traffic ensues. Why?

To be able to use Studio at all, one cannot have internet connection, which makes retrieving files and textures from various locations an absolute pain.

When one has a lot of VIZPARK plants scattered, one can neither rename the scatter items to know what is what and one cannot change the order. If dragged up or down, they eventually snap back. The Modifiers window is tiny and cannot be enlarged. One has to scroll up and down through a long list of elements that all have the same name. Switching one on or another one off is a guessing game.

Another Studio bug. When clicking in a lister name to rename an object or material, a thin green border surrounds/highlights the present name and makes the letters barely readable.

Another Studio bug. With WLAN or ethernet based internet connection, not only do many actions slow down to a near halt, also the core renderer does not start and has to be killed with the task manager.

And another one. When clicking on any of the viewport's 2D viewing icons, clicking on the leftmost to view the 3D scene again defaults to the built-in Perspective camera, not the one one was currently using.

Hi Feynman,

I think sometimes you use the word "bug" too lightly, but thank you for reporting the problems you see.

feynman wrote:And another one. When clicking on any of the viewport's 2D viewing icons, clicking on the leftmost to view the 3D scene again defaults to the built-in Perspective camera, not the one one was currently using.

Let's say you don't like how this works

feynman wrote:Another Studio bug. With WLAN or ethernet based internet connection, not only do many actions slow down to a near halt, also the core renderer does not start and has to be killed with the task manager.

This one I cannot reproduce. I always work connected and that premise alone does not lead to your conclusion, I think.

feynman wrote:Another Studio bug. When clicking in a lister name to rename an object or material, a thin green border surrounds/highlights the present name and makes the letters barely readable.

Noted down.


Regarding the modifiers list: agreed and I would add more things; noted down. This would be an improvement more than a bug, though.

Regarding the issue with the Texture List, I cannot reproduce it. In my case, non used textures do not appear in the list; if i delete an object its related textures disappear from the list if they are not used anywhere else. If the texture has the same name but it's in a different folder it's considered as a different texture (because you could have two "black.jpg" textures in different folders that actually are different); the texture that shows as "not loaded" probably is corrupt and cannot be read for some reason.

Regarding the problems with the UV sets, many things were fixed in 4.2.0.2/4.2.0.3, so I would suggest to update.

Regarding the problem when the computer goes to sleep, well, if the OS is stopping the graphics card, the OpenGL will not responde; I'm not sure if it's even possible to recover from that. Probably the same thing will happen with a video game. In windows you can specify what is disconnected when the computer goes to sleep, probably if you don't allow the OS to disconnect the graphics card, it won't happen.

Cheers!
Fernando

This one I cannot reproduce. I always work connected and that premise alone does not lead to your conclusion, I think.

Well here it is so. Whether a laptop or a render node - when online many interactions are excruciating slow. All Windows 10s are up to date. So what do I explain to all my users?

feynman wrote:Well here it is so. Whether a laptop or a render node - when online many interactions are excruciating slow. All Windows 10s are up to date. So what do I explain to all my users?

Well, it could be happening that all the computers are pulling from the same network drive? I don't know how you are organizing the work exactly, but I can imagine some situations that could produce that.

Usually, when you load a scene into Studio, it tries to locate the textures in the original folders stored in the file; if the textures are not found in the original folder, Studio will first look in the same folder of the mxs file, then in a "textures" folder next to the mxs file and then in the paths specified in Studio Preferences. If everything (the mxs file, and the textures and dependencies, the original paths,...) is located in a not very fast network location and Studio cannot find any of the textures in the scene.... that will probably take a lot of time to load. It would be much faster to make a pack and go and work locally in your computer.

I hope this helps.

Best,
Fernando

All textures, materials and assets are on the local drive of the computer.

A click on FIRE means 30 seconds waiting time and network traffic, even if no browser runs in parallel. Same goes for saving files, opening files, clicking Update to render an MXM preview, and many other actions. The only UI elements reacting normal are numeric and text input fields.

Hi Feynman,
Does that happen with any file open or only with big files? I understand it does not happen with an empty scene, right?

Best,
F.

It happens with a single plane from the Library and also new/empty files, as well as old and new small, medium and large files.

A click on FIRE or UPDATE in the MATERIAL EDITOR panel means up to 30 seconds waiting time, also saving such empty file takes very long before something happens.



Also changing the view while FIRE is running makes FIRE stop for a while to then continue, the same while assigning a different material or adding an emitter while FIRE is running.

We're really trying with much goodwill to evaluate Studio use for industrial, product and packaging design (Alias, Creo, SolidWorks, Rhino, NX, Catia) one more time, but the many bugs and user interface deficiencies are just very frustrating, thinking what with a bit of care it could have been, not that it is your personal fault.

Hi Feynman,

I cannot reproduce what you describe here. I'm not sure what's causing all those lags, but that's not normal.
I have recorded a video showing how Studio performs here in my machine (no fancy hardware): https://drive.google.com/file/d/1x-Xka9 ... sp=sharing

In the video it takes a bit too much time opening the standalone material editor, but it usually does not take so much time (it was the first time in the day). In general it's quite agile. I only experienced lag when the scene has a lot of geometry.

Best,
Fernando

Thanks.

Well, here it's all very much unusable once a PC or laptop is connected to the internet. No other software shows this symptom, so it must be related to Studio or RLM. Something constantly interacts online, when online is available.