Maxwell Render | Official public forum

Hi Jd,

.. first I must mention that the new plugIn is truly new.. I was wishing for such a head up display in rhino itself for command history and status bar,..etc. for a long time.. yours is a very nice implementation and the 1.6.8 version is also not affecting display performance anymore. ( there was a ~50% impact on framerates for me before)

.. now back to the problem:

Copy and paste is sometimes awfully slow

it is actually not a new issue, but i left it aside as it was not showing up all the time.. but i am now pretty sure that it is related to the maxwell plugin in some way(it never occured to me when the plugin was not loaded); it takes 30sec or more to copy just a little bit of geometry in the same place. My first guess would be some issue with textures on the network.. when I paste geometry that comes from within the file, the plugin checks for duplicate materials.. after I click either option it pauses for those +30sec.

Anybody else noticing any delays when pasting geometry, too?

I mentioned the network because at first i noticed that when i opened the top folder of my entire material library(on server) from within the material browser of the plugIn, it also stalled but even for about 4 to 5 min..
so since then I just browse directly to "metal", "wood",etc... folders instead, speed is just fine then.
It shouldn't be the network speed .. as during that stall load on network is really low..

actually there is a similar issue with mxcl... files with really big bitmaps ( did some tests with 6000 & 8000 pixel untiled woodfloor textures) take ages to load, but the network just crawls at 5% .. where it theoretically could be done in ~1o seconds .

could the issue be on my side ? ( filecopy over network works just fine at +50mb/s)

Hi polynurb,

It is entirely possible that copy/paste, in the CTRL+C/CTRL+V fashion may be very slow, depending on the model. When you do that, what actually happens is that a whole .3dm document is saved in a temp location, then imported when you hit paste. This is entirely different than when you use Rhino's Copy command - in that case, just the geometry is copied, along with the attributes which are attached to that geometry. So, since the plugin stores things in the object attributes, and the copy is local to the current document, material version-resolution is completely unnecessary. With copy/paste, this is not the case, and the plugin has to get some direction on which 'version' of things you want to use - either the version in the current document, or the version in the 'temp' document being pasted in. After you make the choice, any lag should be directly related to the complexity of the current document, as well as the one being pasted in.

In either the next version, or the version after that, I have a new way of working with plugin Materials, which will completely remove this issue. Materials will still be stored directly in documents, but they will also be referenced from a custom plugin-managed material database. So, the ones stored in a document will only be used when a document is opened, and there materials which are not currently in the database - otherwise the database version will be used. This will mean that the plugin will no longer have to do this resolving of competing versions of materials, so any slow-down on copy/paste should be completely eliminated.

Regarding network MXM browsing either on a network or not - it is definitely not recommended to point the browser at a top-level directory, since it will recurse all subdirectories in order to build the tree. On the local machine, this should not be too big of a problem unless you point at something like your entire C:\ drive - for example, my default location is the materials database in the Maxwell folder, and the browser parses this tree in just a fraction of a second. The thing about it is, if it is slow on your network, I really don't know what could be done about that - the plugin is really just asking the OS for lists of folders and sub-folders - if there's a real problem with network latency, it is pretty much out of the plugin's control, i.e. there's nothing I know of code-wise that can let it search directories any faster. Of course, I'm only talking about the plugin - I have no idea how mxcl works with bitmaps.

JD

JDHill wrote: what actually happens is that a whole .3dm document is saved in a temp location, then imported when you hit paste....

wow, i wasn't aware of that..

I have been using many 2d features lately , like linetypes, hatches, layouts,..
propably the file got too loaded together with the 3d data & materials.

JDHill wrote:Regarding network MXM browsing either on a network or not - it is definitely not recommended to point the browser at a top-level directory, since it will recurse all subdirectories in order to build the tree.

..yeah I know.. but as you said it was fine as long as the database was local, and i liked to browse without thinking

JDHill wrote: they will also be referenced from a custom plugin-managed material database.

..hold on.. does that mean we will have some centrally organized database, that keeps track of the materials we are/have been using and their changes made to them?
I never used the "referenced" mxm mode, because it was easier to freeze stages of process into a file. But working like that i often found myself browsing trough old .3dms searching for materials lost somewhere on the way. A program for managing worksessions would be very welcome !

...and as always, it is a pleasure to read your fast and mind-expanding answers.. (just had some troubles recognizing you lately.. )

cheers,
polynurb.

The database idea was created for use in the SolidWorks plugin, which, besides for that aspect uses almost all the same design as the Rhino plugin. It was done there because:

1. parts-by-reference is not a feature, it's pretty much how things work, period
2. there can be multiple documents open

Therefore, rather than having some version resolution issues like we have in Rhino it was really much worse, since you can just switch documents and have things getting unsynchronized - not to mention all the references when parts are put together to make assemblies. So two things were clear:

1. the plugin would use it's material format, which is text-based, to enable storing materials directly in each document. This is for portability that doesn't rely on any specific .mxm file being present and at any specific path
2. materials needed to work in a by-reference manner in order to maintain synchronization between documents and referenced parts

So basically, we have this window:



This looks alot like the file system, and in actuality there are files for each of these Materials, but here, the tree-structure is virtual so files only need to be read/written once per session. Rather than being located in any random user-specified location (as is the case with .mxm files), they are stored in a well-known (to the plugin) directory, and they're not named in a readily-readable fashion - they are named by unique a ID which is created when the Material is created, and never changes over its' lifetime. So, it is possible for the plugin to have two Materials which are duplicates of each other and still know the difference between them. When you open a document, the plugin reads the materials stored inside (again, for document-portability, full materials are stored), then looks up their IDs in the database. For each one which is found to exist, the stored copy is discarded, and the database version is brought into the scene. For materials in the document which aren't found in the database, they're immediately added.

Besides for storing materials, you can see the row of buttons along the bottom: these are pages which look alot like the one shown, except they hold saved BSDFs, Emitters, Textures, etc. - you can drag parts of Materials back and forth between the Material Editor layer tree and the database window. Just a note, only Materials are handled in a by-reference manner. Individual components are always copied back and forth, though it is entirely possible to edit them (using the Material Editor) while they're 'orphaned' in the database.

There are still some usage details that I am working out to make this flow in Rhino, but it's really much better than the current system. The location of the database is user-configurable too, so a few people (I don't know how many, it's not really an industrial-strength database, it's just coded by me) can share the same material database by locating it in a common location. This enables some interesting scenarios for offices which have a few different people who need to do work on the same projects.

JD

now I did miss something..
on the other hand,... better that i didn't know until now

that is ingenius.. so node based mxm management exists already.
i always considered the actual layers to be more like a "basic material";
quickly setting up new materials from an existing toolbox or "palette" is an extremly convinient way to work, imho

also, your database approach would make it possible to create an unlimited amount of "virtual" materials, that only exist in some graphical representation...

( these are the coolest nodes I saw in a long time; In this case by Mr.Rutten / McNeel)

.. and you export to a real mxm only if you need to take them with.

another latent problem, with all render engines/material editors ( i hope it is not just me.. ) is messing up the settings of a material over time...
in short: you just did't save the version that looked the best, but only figured it out too late....
if all is database ( provided that the texture library is consistent) then you could tell the software to make an "autosave" every x minutes, and then be able to browse the creation of the material in 4d.. maybe even together with a "preview filmstrip ". (I know it sounds a bit futuristic )

polynurb wrote:now I did miss something..
on the other hand,... better that i didn't know until now

that is ingenius.. so node based mxm management exists already.
i always considered the actual layers to be more like a "basic material";
quickly setting up new materials from an existing toolbox or "palette" is an extremly convinient way to work, imho

also, your database approach would make it possible to create an unlimited amount of "virtual" materials, that only exist in some graphical representation...

Just to clarify, so you don't think this is something more than it is, when I wrote 'Individual components are always copied back and forth...', specifically that means that individual BSDFs, Emitters, etc., are not done by-reference. That is, when you drag a BSDF from your library into a new Material, then change its' color in the Material, it will not affect the original BSDF that you dragged in - when you dragged it, a clone was made of the database BSDF. So they are used more as templates for building new Materials from. I am sure it would be possible to make everything done by links, but it's about a hundred times more complicated than keeping the by-reference operation at the Material level, so it'll be done that way at least for now.

For Materials though, there's little to think about while you're using the system. The in-memory Materials are flushed to disk from time to time, so there's much less chance of losing changes you've made if Rhino crashes or something like that. It just requires a bit of an adjustment in how you think about things - you will be able to consider Materials as something that exists completely outside of the context of Rhino. Actually, since I have this working here, I have the same list of Materials in Rhino as I do in SolidWorks - changes made in one app are shown next time I open the other app. Of course, that's really not rocket science, since the same would be true if the plugin just used paths to link to MXM files, but in that case you'd have a much looser paradigm than we have now, where you'd use MXED to edit things, and there wouldn't actually be complete Materials stored in the documents. So the main things we gain doing things this way are complete redundancy and document-portability.

.. and you export to a real mxm only if you need to take them with.

Probably the only time you'll ever touch an MXM is when you've downloaded one from the MXM gallery - to import it into the database. Thereafter, you'd only need to export as MXM if you wanted to give the Material to someone not using Rhino or SolidWorks.

another latent problem, with all render engines/material editors ( i hope it is not just me.. ) is messing up the settings of a material over time...
in short: you just did't save the version that looked the best, but only figured it out too late....
if all is database ( provided that the texture library is consistent) then you could tell the software to make an "autosave" every x minutes, and then be able to browse the creation of the material in 4d.. maybe even together with a "preview filmstrip ". (I know it sounds a bit futuristic )

I kind of touched on this above, in-memory things are flushed to disk every so often...not so much on a timer, but at times where you've done some significant action, or when you might not notice any lag of actually pushing them to disk because some other processing is taking place. It's pretty easy to save a Material at a point where you think it's pretty good, but you would also like to tweak it some more: since there will also still be a Scene Materials Browser like there is now, any time you want to, you can drag what you're working on from the browser, and up into the database to save a clone of it...if you later don't like what you've changed, you'd just basically do a 'select assigned objects' on the modded Material, select the previously-saved clone in the database, and then do an 'apply to selected objects' to get back to the point where you had started experimenting. As far as having any kind of automatic 'history-aware' Materials, of course anything is possible, but at this time that wouldn't really be in the cards...it's a cool idea though.

Cheers,

JD

Hi polynurb & JD

a lot to read for a monday morning ...
I just wanted to add, that this copy/paste-lag has been bothering me for quite a while too (I'm oftening copy/paste objects from one .3dm to another and since those 3dms often go above 100MB, it takes up to few minutes while working on a network drive).
Also the "overwrite existing materials" dialog every time I copy something or update a linked reference file gets annoying, so I'm glad to hear about the new way of handling materials. I don't think I understood it completely, but I'll hope to understand it when it's implemented. As far as I could understand, it's a great way for material organization.

It's a pity, that not all maxwell plugins will benefit from the same method of a material database and it's just a thing for the rhino/solidwork users. Wouldn't it be reasonable that the whole maxwell system could work with this method? I'm sure, it's not your decision, since you're only responsible for those two plugins, but in the long run it would be a nice feature for all maxwell users.

Additionally, I wanted to add some thoughts to the material editor workflow... Something which could also be improved, I think: While adjusting a material, you often change some value, then let the preview rerender. But it's quite difficult to see the changes which were caused by your action, since you can't compare it to the version before. It would be nice to go back to the version before and directely compare the two preview images or even the two material settings.

Greets,
Kami

Hi Kami,

It would be great if all the plugins could be written using the same code, but it's just a technical impossibility. Luckily, both Rhino and SolidWorks have Microsoft .Net-based APIs (application-programming interface) available, so I am able to create a generic base of functionality, then customize the connection of that to each application with a single library for each that handles the actual app-specific work. But this kind of code-sharing is not universally possible - for example, I can't even use any of my existing code to write a plugin for the future Mac-based version of Rhino.

Regarding your second question/suggestion, that is basically what I was addressing in the last paragraph of my previous post. Basically, there won't be this idea of 'history' for Materials, but most anything is possible in the future.

Regarding:

Also the "overwrite existing materials" dialog every time I copy something or update a linked reference file gets annoying...

Please see Plugin Options, specifically the 'Suppress Material Conflict Dialog' and 'Prefer Linked Materials' options. These are explained in the plugin's help file, but basically if you set 'Prefer Linked Materials' to Yes, it is equivalent to always giving the go-ahead to overwrite existing Materials with those contained in a pasted-in document. Using those options you should be able to make the plugin behave how you want it to without it needing to ask you all the time.

Cheers,

JD

Hello JD,

Too bad for the rest of the Maxwell guys In my opinion, the Rhino plugin is getting so much better than some other parts of the program. Basically it's the reason why I stayed with Maxwell Render, because working with studio is tediously. It just does not have the same usability as the plugin.

Regarding your second question/suggestion, that is basically what I was addressing in the last paragraph of my previous post. Basically, there won't be this idea of 'history' for Materials, but most anything is possible in the future.

Though I didn't understand that completely... In the end I'm not asking for a complete history but just a view of the previous state to compare these two previews (just like the old color/current color field).

Please see Plugin Options, specifically the 'Suppress Material Conflict Dialog' and 'Prefer Linked Materials' options. These are explained in the plugin's help file, but basically if you set 'Prefer Linked Materials' to Yes, it is equivalent to always giving the go-ahead to overwrite existing Materials with those contained in a pasted-in document. Using those options you should be able to make the plugin behave how you want it to without it needing to ask you all the time.

Thanks. I just notice that I've never read the whole manual...