Thanks, I'll have to check it out, then. A process, be it SketchUp or maxwell.exe, should consume a negligible amount of processing capacity, in comparison to that used by the engine. The only thing to do, then, is to measure.

@jason_maranto said:

@valerostudio said:

If we are using Suite are we looking at cleaner less-noise renders? That seems to be something that was tackled in this update?

the full Maxwell Render Suite will always clear faster in the same amount of time due to the additional processing power it leverages.

Technically, this should not be the case (with the licensed Standalone, using the Production engine), though I have not personally run any comparisons. The engine should be identical inside; the Draft engine, on the other hand, may take a good deal longer in situations involving more complex lighting.

@idahoj said:

I'm looking to evaluate Maxwell, but I'm on a Win XP PRO 64 bit system. In checking the system requirements on the Maxwell site, it appears my OS is not listed. Should I take then with some authority that Maxwell isn't suitable for my system?

It should work fine on XP Pro x64, though I have never personally run it on that platform.

@valerostudio said:

Nice model. Love it! Any chance there will be more on the way like this? So looking at your setup in this file, we still need to create a sphere and apply the IES material to that? I did some tests and it seems like size of the sphere does matter, so whats the general rule, .5" diameter?

No, not really any more models where that one came from -- I mostly wrote it to help me with the coding. And yes, that is how it works: you just apply an IES material to a piece of geometry (a group or component, so that you have directionality); I chose to do it that way because this is how it works underneath, in Maxwell, and allows you to control the output of banks of lights from a single material. As for questions on the use of IES in general, I wouldn't be a good authority on that, since they have never been a part of my own workflow.

The 2.6.10 plugin is available here, so you may be looking at a cached page, Jason. Since I got feedback indicating that some people did not like the zero-impact .zip-based plugin installation, you will see that there are now also two OS-specific installer-based packages, for use with SketchUp 8. The universal .zip-based package is still available for people who still prefer that, or are using another version of SketchUp.

Regarding IES support, if you look in the new [plugins]/maxwell/res/ies folder, you will find a fairly sizeable collection of IES & LDT files. For fun, I attach below an example DC that demonstrates one possible use of IES files in this version of the plugin:

And here is the DC:

ies-dc.zip

Please don't take it wrong, but I generally think such polls are akin to: which is the best overall tool?

• hammer
• screwdriver
• paint brush

By the way, do you think it's okay if I vote too? I was a Maxwell customer long before I was ever involved in its development.

I don't mean to seem evasive, but as a matter of policy, I never answer that question with any precision. I plan on putting up some pre-release bits for customers pretty soon (the plan for this is on the order of days, not weeks), but I won't make any estimate on timing for a public release.

There will be an IES material character in the next build.

@surfingalien said:

finally, one last question (sorry, I have registered to the MR forum but I'm still waiting for the admin to unlock my account for posting): when I try to register my copy of Maxwell I get this error:

I had a quick look at the knowledgebase/FAQ section but the only thing I found is about admin privilege (which I own -
I'm on Mac OSX 10.6.8). any idea about it?

thank you in advance,
Alessandro

Hi Alessandro,

I would like to help, but the licensing application is not mine, so I am not aware of the meaning of this error message and cannot find out until after the weekend. It is my understanding that you should have received an email, and that this may contain information enabling you to log in to your account at the NL customer portal. From there, you can send a message directly to tech support, so that they can get working to resolve this first thing Monday morning (Madrid time). I would expect that your forum account will also be upgraded sometime Monday.

Just as a shot in the dark, you could try running the licensing application directly; you should find it located @ [plugins]/maxwell/lic/LicenseValidator.app. I suggest this on the strength that, judging from the error message, the application may be having trouble getting permission to write its license file, and that running it directly might help with that.

I apologize for the inconvenience.

Cheers,
JD

@jason_maranto said:

You can only save out as .png -- no other file types are supported.

I don't want to get into providing support via this forum (we have a forum for that already), but to clarify this point, you can actually save using any of the following formats:

• .bmp
• .tga|.targa
• .jpg|.jpeg
• .png
• .tif|.tiff
• .jp2
• .ppm
• .pbm
• .pgm

This is why you need to specify the output extension in the save file dialog (I see from gilles post that I need to provide a more informative message when no extension has been given). The underlying limitation to which Jason was referring above is that the output color depth of the standalone plugin is limited to 8 bits per channel; naturally this is not the case with a full Maxwell Render Suite license.

@unknownuser said:

but the free version watermarks didn't show up

Just to clarify, the download page originally indicated that there would be a watermark, but that was never the case, and the web people have since corrected this.

I'm very sure of that, and it was not my intention to imply otherwise. It just sounded like you were keeping that possibility open, so I felt the need to speak up. If it's your intention that it be strictly opt-in though, the idea sounds nothing but good to me.

@dan rathbun said:

I think allowing users to force all webdialogs into GCF, may open up Pandora's Box, and cause problems. Testing will tell.

I hope you don't even consider doing that. It is not simply a matter of possibly breaking some plugins in relatively minor ways: there exist plugins which could potentially cease to function entirely. My plugin, for example, uses Silverlight, and I neither know, nor plan on finding out, how well it is supported in GCF -- if it is even supported at all.

@adamb said:

JD, I think you've got to bite the bullet and use the COM interface to get the ISkpMaterial, then extract a ISkpTexture on which you can call WriteToFile().

On a related note, anyone else experience that TextureWriter is stupidly slow for large images? ie a model has a 2000x1000 bmp texture and Texturewriter can take minutes to write it out.

Ugh. I'd rather not do that. And yes, my recollection is that WriteToFile seemed to be quite slow. But I don't use it; if WriteAllTextures fails, I fall back to using WriteTextureFileFromHandle. Can't say that I specifically compared the performance of that with WriteToFile though.

@thomthom said:

I thought COM was a Windows thing...

Not really, COM is just the definition of a set of contracts which are designed to allow unrelated components to connect to and obtain services from one another; roughly speaking, is_a? and respond_to? for C++.

And thanks for the idea of using a Definition; that's perfect.

Yes, that's a nice idea in theory, but the point is that it is difficult to discern any consistency regarding if/how/when those calls work. I have in the past, and just now again, been going over this, trying to infer what happens, and I do notice now that it has much to do with things working differently in various contexts. I have three basic scenarios where I end up needing to write a new texture:

1. a textured material is selected for the first time
2. a textured material's color is edited via SketchUp UI
3. a material's color is altered via my UI -- goto (2)

In cases (1) & (3), I have found no way to prevent the necessary add_face, material=, erase_entities sequence from showing up in the undo stack, nor have I been successful in consolidating those three things such that they would appear as a nice, single undo item.

Case (2), however, apparently executes within a special context, where the only item added to the undo stack is an Edit Material action, regardless of what other actions occur as a result of it (i.e. apparently, within the context of onMaterialChange from a plugin's POV). So that's where the idea came from that what I do wasn't showing up; it really wasn't, but only when triggering the action via SketchUp's material UI.

In cases (1) & (3), with no start, abort, or commit, and after drawing a rectangle, I seem generally to obtain this sequence:

• Undo Properties
• Undo Properties
• Undo Rectangle

Using start with [abort or commit] around the whole operation, this becomes:

• Undo Properties
• Undo Erase
• Undo Assign Material
• Undo Create Face
• Undo Write Texture (the name given to start_operation)
• Undo Rectangle

Attempting to use multiple starts/commits, with seemingly-logical combinations of the 3rd and 4th start_operation bool parameters, one can achieve different, but not necessarily better, results. On the hunch that maybe it would work better if an entire method were wrapped, I tried that too, but it made no apparent difference.

Therefore, I have to say, I do think that overall, the undo stack stays cleaner (would that it could be done truly transparently without all this hackery) when you do not use start, abort, or commit, with this specific operation.

I'd be curious to hear what you observe there, since you say you were working on the same thing.

@unknownuser said:

and i guess it's this temporary face thing that causes it.

I understand, but actually, it's not related to this issue at all, and it should not happen in all cases. If I set a single attribute on the model, then SketchUp will put up that dialog. So I'll look into it and see if there are some cases where I am, but do not strictly need to be, persisting data.

Of course, everything here changes with the new ModelObserver.onPreSaveModel method. I would obviously prefer never to store anything at all until you are actually saving the document.

@thomthom said:

Using abort didn't work well?

Not as far as I've been able to determine. I've tried aborting rather than erasing, committing after erasing, using different combinations of flags in start_operation, and I have not found any way to handle it cleanly. Were this Cinema, you'd just make a new document, in memory, do the work there, and then delete the document.

@thomthom said:

@jd hill said:

If you skip those, you can stay out of the Undo stack.
? How do you mean? You avoid the undo stack by not using start_operation?

Well, I thought that was the case, but now double-checking, it certainly seems not to be.

I don't think there's any other way. I have worked over this particular piece of code a lot...I have tried using a Group instead of a Face, but that becomes a pretty bad idea when the Outliner is opened and there are lots of Groups/Components. I've tried all different combinations of start_/abort_/commit_operation, and haven't found any combination that yields a useful or predictable result. If you skip those, you can stay out of the Undo stack. Which is good, because it is only when using them that I was able to produce a few bugsplats when the records they added were undone.

I would kill for a better way of getting a texture on disk.

Adding a temporary Face in order to write out a texture via a TextureWriter.

@adamb said:

Hi,

There appears to be a bug in the Maxwell SketchUp plugin. Essentially it presumes that no other plugin will be firings its Observers it sets up as SketchUp starts up - obviously not a great assumption. (Also if you turn on $DEBUG, Ruby complains about a few uninitialized instance variables as the maxwell plugin loads which is probably not ideal.)

Anyone know how to contact the authors?

Adam

Apparently, during startup only, SketchUp doesn't like me doing something I do in my onMaterialAdd method. I was not previously aware of any problem here, because that method is never called when SketchUp adds its own materials; however, it is called when a plugin does.

I'll take care of it.

JD

If you have an API which supports EnumWindows, you can use GetProcessId and GetWindowThreadProcessId to filter on windows in the current process.

@jim said:

...this plugin...select[s] the tool on new and opened models instead of the tool.

Heh, I wrote that one too. It gives a whole new meaning to this: