[kami]

Hi Jeremy

I quite often get the message

Maxwell: errors were detected in meshable geometry - IDs have been listed in the log viewer. objects
Maxwell: which generated the errors are now selected in the viewport (note: you may see nothing - it
Maxwell: may not be possible to display some of them). if they later become unselected, and you wish
Maxwell: to find them again, please try one of the following methods:
Maxwell: - use the command: 'SelBadObjects'
Maxwell: - use the command: 'Maxwell_CheckFixAndReportBadGeometry'
Maxwell: - highlight the object's ID in the log viewer, right-click and choose 'Select Object'

But very often, no objects are selected which is due to the bad geometry being inside a block instance.

This is nothing serious, just wanted to let you know. If you think this is something you would want to change?
For example to highlight the blocks that are concerned?
I tend to ignore the message and only act if I am missing any important objects on my rendering

[JDHill]

I'd guess you're importing a good deal of geometry from other applications, then. You'd be correct to say that instances of block definitions containing offending geometry will not be highlighted, and I will see about changing that.

[kami]

For the network rendering, in the options tab, there is a tick if you want to start a manager and a node when you start a network rendering via maxwell.
By default, it is set to start a manager and a node. I think this is not the ideal preset.
I deactivated this option on every machine, because it creates confusion for the network, if there are several manager running. And if you really use the network rendering frequently, the manager is running on a server and the node starts automatically with windows.

Now I just realised that on a lot of machines, the option is activated again.
Somehow with latest update, it made a reset to the option, so that a manager and node is ticked again.

Could you put the default to disabled there? I think this would be the safer option ...

[JDHill]

I understand your point, but if it were disabled by default, then by default, when a person clicks the Render to Network button, it wouldn't work. So I don't think I'll change that. What I'd be more interested in would be how your preferences got reset, because there's no reason that should happen just from installing a new plugin. I think I recall in the past that you may be using some unconventional methods of managing the plugin preferences, perhaps distributing them from one machine to another, or linking preferences on one machine to the files on the other -- is there anything like that going on in this scenario?

[kami]

No, I'm not linking preferences. I've asked about that but never did it because you suggested not to, if I remember correctly.
The relationship with the update was just my assumption. I know that I changed it on every machine we have, but now it was activated again on more than one. Not sure why, but I'll check and make sure it is disabled again on every machine and report back if it changes back again.
I also understand your point about the network rendering not running when it is put to disable. But I can remeber a dialog asking whether you want to open a manager as well, or was that an older state of the plugin? Could that be something for the first launch?
I would prefer having a default setup that works without risks in an environnement where the network render is used a lot opposed to a setup that is made for people not knowing how the network render works. Because when you just launch the render on one machine you would'nt have any advantage because there is only this one node launched.

[polynurb]

I would prefer having a default setup that works without risks in an environnement where the network render is used a lot opposed to a setup that is made for people not knowing how the network render works. Because when you just launch the render on one machine you would'nt have any advantage because there is only this one node launched.

i'd prefer the secure way as well.. i had it happen a few times that a second manager started up accidentally, where one was already running on another machine. Considering the fragility of the net render, it is something i'd prefer not to happen, although until now i could just quit the second instance without any negative effect.

[JDHill]

So, change the Start Manager default to No, but whenever it is set to No, show a dialog asking if you want to start the manager, but only the first time you try to render to network. That just seems like strange behavior to me (again, I do understand why you want it), and when I find people asking me to implement strange behavior, I first wonder if we're maybe talking about an answer to the wrong question. Here, that leads me to think of two alternate approaches:

• 1. Change the behavior of the manager: it should be capable of finding out if there is another manager running on the network, so if it finds that to be the case, it could just shut itself down, after popping up a dialog to let you know.
  
  2. Change the Render to Network command: add StartManager and StartNode options to Maxwell_RenderToNetwork, where the option values are taken from plugin Options values by default. If you did not like this behavior, you would edit the toolbar button macro, or create a new button, to override those values.

Either would solve your present problem, without redundantly asking someone a question they've already answered (in the case that Start Manager:No is what the person actively wants, and not just the never-been-changed default). The first would seem to me to be the cleanest solution, and would also serve as a subtle education for people on why they may or may not want to start a manager on the local machine.

[kami]

I think the first option would be the proper one, but that would mean a change in the mxmnetwork (eg. for Maxwell 3)?
The second one would work as a a workaround, but does not seem better than the current solution to me.
So maybe just leave it like it is now? Theoretically it works fine. I hust have to make sure I disable the tick on every new machine I install.

Maybe Nextlimit is reworking the network system a bit for the next release (I hope so, since it is still a bit unstable).

[polynurb]

it is really no too big deal, but it happened to me eg. when i logged in on another machine in the domain which had the check still set and i forgot about it before i sent a job.

i always start the manager before starting any node and from within rhino, only the local node can be fired up.
maybe other people do turn on their nodes first, and let them sit until a manager comes up, but imho that is not a good thing to do as it creates unnecessary broadcast traffic on the network. that is just why i never found the default behavior practical.

your suggestion 1) seems like the best solution, but i wonder if it creates more complexity than necessary?

[JDHill]

I talked to the mxnetwork developer, and there are indeed some changes planned regarding this issue (multiple managers) in the future.

[AlexP]

Jeremy,
Is it possible that mxs proxy mesh is put on block layer not current one?

[JDHill]

Should be -- I'll take a look.

[kami]

When you do a Maxwell_GatherFilesAndMakePathRelative it copies all the textures + the HDRI lighting into the subfolder textures
But when you try to start a network render out of rhino (without dependencies) afterwards, it gives a message that the HDR is missing, because it seems to be looking for it under the path where you exported the MXS scene (textures/....hdr) still as a relative path. The export runs fine, but the network monitor shows an error message.
Is this a bug?

[polynurb]

When you do a Maxwell_GatherFilesAndMakePathRelative it copies all the textures + the HDRI lighting into the subfolder textures
But when you try to start a network render out of rhino (without dependencies) afterwards, it gives a message that the HDR is missing, because it seems to be looking for it under the path where you exported the MXS scene (textures/....hdr) still as a relative path. The export runs fine, but the network monitor shows an error message.
Is this a bug?

a bit explanation about the command and the differences to pack&go

http://www.maxwellrender.com/forum/view ... 05&t=40198

[JDHill]

The main point would be that the two (Pack & Go and GatherAllFiles) are intended to serve completely different purposes. Pack & Go is designed to give you an MXS file, with textures, that you can zip up, move elsewhere, unzip, and render. GatherAllFiles, on the other hand, is intended to make it easier to move a 3DM to a different location, which is something that you should rarely need to do.

Regarding the error message in the network monitor, all I can tell you is that in a Pack & Go MXS, the texture paths written are literally of the form "textures/image.hdr", so they should be found, if that is a valid relative path from the MXS. This is the same for all paths, so if you only have an issue with HDRIs, that might tend to imply there could be some problem with loading HDRIs, specifically.