[JDHill]

Thanks for the report, could you let me know which version of C4D you're using? Point-by-point:

1. 'no preview scene found' - if you click the top node in the material editor tree, the main page for the material will be shown. What is indicated in the Preview Scene pull-down? Is there an MXS file in your Maxwell/preview folder that corresponds to this name? What if you change the selection in the pull-down? FWIW, I just got done rewriting this so you will be able to set which one shows up as the default.
2. unspecified C4D crashes - if this happens, it would be good if you could look in the C4D _bugreports folder to see if there is a _BugReport.txt file for the crash. This may help me see what is happening.
3. missing geometry - does this mostly refer to when you are using (C4D) instances? Just before release, we found a problem when both of the following conditions are true:

• - the instance and the reference do not have a common parent (i.e. other than the document itself)
  - the instance (or its top-level parent) is lower in the object tree than the reference (or its top-level parent)

If this is the case, try grouping the objects under a null object - that should take care of it. If not, it would be great if you could email me a simplified file that shows the problem.
4. 'triangles on flat surface' issue - what type of object is this? Again, an example file would be extremely useful.
5. 'instance export problem' - may I assume you are talking about Maxwell instances? I am working on a system for working with them.
6. wish: transparency and clipmapping in view - I'm not clear on what you mean by this. Do you mean, if you have a weight map in a Maxwell material which you are using as a clip map, that the weight map when shown in the viewport should have the black parts turned in to alpha, or?
7. wish: C4D to MXM conversion - since this already happens automatically during export, I assume you mean you want to convert the C4D materials into Maxwell ones while still inside of the C4D document?
8. 64bit crash - as with the other crash item, please try to see if there is any info in the _bugreports folder. As far as I know, the testers do not have any open issues specific to running on x64.
9. texture-switch crash - was this an isolated incident, or can you repeat it?

Thanks,

JD

[Becco_UK]

Thanks for the time spent developing this 'new' plugin - not tried it yet but there isn't the usual 'outrage' I so assume it's a good release. I will start using it when I commence my next Cinema4D project. Thanks again.

[MS]

The new plugin looks promising as other users have already mentioned in this (or other parallel) threads before. As it is first release of new version I have to pay compliments to JDHill!

I still have not tested the new plugin much, I have to finished my current job first. But I have forced myself to read a manual. Based on this I have some questions/wishes:

This is a part where linking of MXM files is described:

* a C4D document is opened
* the plugin reads the Materials stored inside
* for each Material which was saved with MXM Linking enabled, the plugin reads its MXM path, and checks whether an MXM file is found at this location (or at any location found in the various search paths)
* if the MXM file is found, the Material is immediately updated with the contents of that MXM file. If however, the MXM file is not found, nothing further happens – the definition of the Material which was found in the document will be used at render-time

Note that, it is possible to modify a Material using the plugin’s Material Editor, regardless if it is linked or not. However, any changes made to a linked Material will be lost immediately when the document that Material is contained in is opened.

I wish this feature could be switched on/off based on user choice. Or some confirmation dialog to appear before doing so would be nice. Otherwise it may be dangerous sometimes – e.g. I modify some material, I forget to uncheck “MXM Linking enabled”, save the scene. Next time I open the scene, I loose all changes I have made to material. (I remember this issue from “my Lightwave times”. I often forget to save object’s material when I modified them in scene mode…)

This is a part where handling of missing files is described:

How does the plugin deal with missing files?

The plugin searches for MXM links and referenced textures in a variety of places when documents and Materials are opened. These include:

1. the /Maxwell/materials database/mxm files directory (recursive search)
2. the /Maxwell/materials database/textures directory (recursive search)
3. the /Maxwell/hdri directory (recursive search)
4. the C4D texture search paths

These paths are also used when attempting to locate MXM links. When a file is not able to be located, a report of the failure will appear in the C4D Console window.

I wish I could specify which location plugin should look into or to deactivate that search at all. E.g. sometimes I take texture from “/Maxwell/materials database/textures directory” modify it to suit my needs, save it to another directory with the same filename. I do not want the plugin find the texture in “/Maxwell/materials database/textures directory” when I for example removed or renamed the modified version of texture, I prefer to get error message like “Hey you… Texture file FILENAME cannot be found on SPECIFIED_PATH.” Or maybe better “Hey you… Texture file FILENAME cannot be found on SPECIFIED_PATH. But there is texture file FILENAME on MAXWELL_DEFAULT_TEXTURE_PATH. Do you want to use it?”

Next three wishes are independent of plugin version:

I wish "Save scene" in Cinema4D saved also all mxm materials and relevant textures to one location – like Pack and Go function from Maxwell Studio does. (e.g. whole scene to be moved to different computer)

I wish "replace during conversion" was available
* Dosch Design (and others) have prepared special edition for MR - models in mxs format
* Wish I could use those objects WITHOUT running Maxwell Studio.
* Put in Cinema4D null (or other) object with special tag pointing to mxs file where desired Dosch MW object is stored
* scale and rotation can be controlled either by "scale" of null or by tag itself
* Useful for trees and similar stuff in architectural visualizations

I wish "Add parameter to filename" feature
* now all renders are stored to "filename.ext"
* wish I could specify "filename_hhmmss.ext" or "filename_randomnumber.ext" so I could simply compare last and current renders. Sometimes I accidentally overwrite previous version of rendered file…

Thank you jdhill for your great work.

[spekoun]

1. The scene preview pullown is emty. But MXED works correctly and "see" all mxm preview scenes
2. I did no find _bugreports folder on my C: So C4D did not make any bugreport?
3. Yes i used instances. I will try group them.
4.
5. I know you are working on instaces. I ment: I hope you finish it soon. Sorry my english.
6. Exactly. If I use transparent maxwell object I want it in C4D viewport transparet too. Same for clipmaped materials.
7. Yes. I would like to trasform C4D mats to Maxwell ones. But it is not so important feature for now. It is just idea.
8. This kind of crash did not save any bugreport, I think.
9. It seems ok now. It was random crash.

Thanks for your effort and quick replies. It is nice to knouw that somebody is working on C4D plugin.

Cheers

[JDHill]

Thanks for the input Martin.

Regarding MXM-linking, I understand where you are coming from, but I tend to think that at some point you just have to be responsible for the decisions you make. In the past when I've gone further than I was comfortable with on some safety-feature like this, it has turned out to be used very rarely, and the rest of the time only served to add confusion for all of the people who don't use it or read about what it does.

Regarding texture searching, those types of confirmation dialogs are exactly what I have been trying to avoid. I am currently doing more work in this area, so I will take your suggestions under advisement. Currently, in addition to searching the C4D texture paths, I am adding five paths you will be able to specify using a new plugin preferences page. While I am doing so, I will add a 'disable default path searching' option, and this should be able to address your specific concern; if it is enabled, the plugin will only search in places you have explicitly directed it to search.

Regarding a 'pack and go' type of command, I will think about how to do this. It is more complicated than it sounds when you factor in texture paths located in linked MXM files, if you see what I mean.

Regarding an 'import-mxs' object, that is a pretty far-out thing to add. Studio has enough difficulty reading some MXS files, so I am unsure about what types of technical issues might be involved in trying to read them into a C4D document - really, the plugin is supposed to be an exporter, not an importer. But I'll keep it in mind anyway.

Regarding auto-naming, that should be no problem, I have such a feature in my other plugins.

[JDHill]

Thanks for getting back to me on that list, spekoun.

1. the plugin is expecting to find a folder named 'preview' in the folder pointed to by the MAXWELL_ROOT env. variable. If the preview list is empty, but the plugin can start MXCL, then it seems to indicate that this folder is named something else, or that it is empty. I'll try to think of other possibilities.

4. I would really like to have a file with one of these walls. I'm not sure what would cause it, but I will take a look.

[MS]

Regarding MXM-linking, I understand where you are coming from, but I tend to think that at some point you just have to be responsible for the decisions you make.

Understood.

if it is enabled, the plugin will only search in places you have explicitly directed it to search.

Yes, please!

Regarding a 'pack and go' type of command, I will think about how to do this. It is more complicated than it sounds when you factor in texture paths located in linked MXM files, if you see what I mean.

This is not a "must-have-function" - I just wanted to have a full list of my wishes in one post.

Regarding an 'import-mxs' object, that is a pretty far-out thing to add. Studio has enough difficulty reading some MXS files, so I am unsure about what types of technical issues might be involved in trying to read them into a C4D document - really, the plugin is supposed to be an exporter, not an importer. But I'll keep it in mind anyway.

This is a misunderstanding. I do not want to import mxs files to c4d scene. I want them to be merged to main scene mxs file during output. In c4d file there should be only "Null" object with link to that object files (same situation as with material files stored in mxm files with link enabled.)

E.g. I have a house.c4d scene with model of a house, I put Null object with "Link tag" to place I want to have some nice tree, set up a link to file nice_tree.mxs. Then I hit "Export..." or "Render". Plugin exports my c4d scene with the house to house.mxs, then it merges house.mxs and nice_tree.mxs to let's say house_with_nice_tree.mxs (or simply house.mxs)

I know it is not so easy to implement - you have to check paths to external mxs files, link to textures in those files, to prepare new tag, and also to write merge script. But maybe sometimes...

Regarding auto-naming, that should be no problem, I have such a feature in my other plugins.

It should help a lot!

Thank you JDHill once more.

[JDHill]

Ah, thanks for clarifying. That is easier, but still may or may not be realistic, depending on a few unknown factors. I'll keep it in mind and let you know when I have anything to report, up or down.

Cheers...