[Richard]

Looking at what he is doing with the SDS2 beta from Solo's videos, whaat is breaking the bank on scripting for SU! I tend to put anyone who can write any form of script in the land of gods!

I have enough trouble with the english language let alone one that aliens bought to earth!

[stefan_kaplan]

Please detach the behavior of Maxwell Sun on/off from the SketchUp shadow on/off.
This is driving me nuts. I have to go back to the Environment tab before every render-test to (sometimes) correct the sun setting...
All the best.

By the way, is SketchUp on fire, JD?

/Stefan

[JDHill]

I'm working on it but it's not been much fun. Did you know that the version of Ruby used in SketchUp is inherently single-threaded? And that Fire is inherently multi-threaded? That makes things a little bit tricky.

[Half Life]

I did -- is it possible to use http://jruby.org/?

I've asked this before on the Sketchup forums and got no answer...

Best,
Jason.

[JDHill]

A nice daydream, but no -- it would be necessary to remove the ruby interpreter supplied with SketchUp and replace it with jruby. And doing so would be a pretty big no-no -- SketchUp was never tested against anything but the ruby interpreter it installs, so it's not possible to guess what far-reaching effects you might run into. Perfectly fine experiment for a hobbyist who knows what they're doing, and who's just playing around on their own machine, but not really a valid strategy for any commercial software.

[brodie_geers]

Stefan, here's a ruby tweak JD posted some time ago on this thread. It works great and does just what you seem to be asking regarding the sun/shadow behavior being linked.

For me the real question is whether the linking should be optional or not -- I haven't answered that for myself yet, and so have not changed it, since making it optional requires both UI and logic changes. So let me know your opinion.

In the meantime, you should be able to de-link it permanently for yourself by going to plugins/maxwell/lib/observers/shadowinfoobserver.rb and commenting-out (i.e. adding a '#' in front of) lines 17-19, so they look like this:

Code: Select all

#              sun_enabled = shadow_info["DisplayShadows"]
#              Util.set_property(model, "environment", "environment.sun_enabled", sun_enabled)
#              Dispatcher.send_request("environment.sun_enabled", sun_enabled)

[JDHill]

For what it's worth, I've simply decided to permanently un-link them in the next build.

[Half Life]

Hey JD,

There's an UV thread in the main forum that reminds me of how much I hate the .25m X .25m UV overide projector in the Sketchup plugin.

The reason I loathe it so is because it took what was a relatively simple process (tiling in MXED) and added extra math into the process...

(A 1m X 1m projector makes it simple to set meter based tiling in MXED, just put in your desired values -- the .25m projector requires me to multiply my desired units by 4 manually)

Don't make me do this -- it isn't pretty... have you ever seen a monkey like me use a calculator?

Best,
Jason.

[JDHill]

It would be pretty easy for me to alleviate your math-related pain...I could just replace the default UV generation with no UVs. Seriously though, didn't we have a long discussion about this on this forum already? It is just not my experience that many textures scale well at a meter.

With respect to MXED, I think you're trying too hard. Put the texture into Meters mode in MXED, upload it into SketchUp using the 'Copy texture to SketchUp material' button in the plugin's MXM material interface, then edit the SketchUp material to be 1m x 1m. SketchUp will generate 1m x 1m UVs, and the texture will be scaled inside of that according to the repeat values you entered in MXED.

Unless of course, there's some reason (other than subjecting yourself to the pain of mathematics, that is) that you're using the UV override. Is there? Because as I've said before, at this stage, that is primarily a last-ditch fallback for when there are no UVs; I exposed it in the UI because I could do so relatively easily, and because it might be useful in some difficult scenarios. It is not yet, however, intended to be a commonly-used tool.

[Half Life]

I really only use it when I have a MXM set up but no image to use in Sketchup to control the tiling -- therefor I'm planning to control the tiling via MXED, which is great and all but the math, man -- the math is killing me.

I've not yet once seen the .25 projector happen and say to myself: "self, that looks like what I want , JD is the UV mastermind .".

It usually goes something more like: "what the hell?!? Ohhhh yeah ... crap, time to break out the calculator ."



Best,
Jason.

[JDHill]

I see, so you use the UV override because in your specific workflow, you don't want any UVs to exist in SketchUp? I suppose that would be (assuming it to be correct) because the textures are large?

[Half Life]

Absolutely! Because through no fault of yours, Sketchup is in fact a total pansy when it come to dealing with Maxwell sized textures and promptly bloats and dies (sometimes)

If somehow Sketchup ever figured out how to display textures at lower resolutions like Studio does then all of this would be moot.

Best,
Jason.

[JDHill]

Okay, I'm just trying to get a handle on when/where this stuff gets used, and why. It's been discussed before about trying to come up with an image-proxy scheme, where the plugin automatically tries to load some lower-resolution stand-in image when you ask it to put your MXM (or other) texture into the SketchUp material. It's a good idea, but it's a little involved and has not yet been a top priority. It would seem to me that this is more of the answer to your specific problem, which is really neither UV nor math-related.

The answer to the issue you raise, i.e. the scaling of default/override UVs, lies not in changing the number used, but in giving you control over that number. Of course that is also strictly a value-add, so it falls behind things like Fire in terms of priority.

[Half Life]

But of course, mon ami -- I never meant to suggest otherwise... I just felt the need to vent my math fueled rage, I'll survive... and Fire will surely comfort me on those long math-filled nights

Best,
Jason.

[brodie_geers]

It's nothing new or brilliant, but the workaround, of course, is to create your own lowres proxy image. It can be a bit of a pain to have to open up another program and convert single images whenever they crop up but I came up with a nice trick that helped with my arroway textures at least, since there are so many of them and they all share a naming convention.

I used Belvedere ( http://lifehacker.com/#!341950/belveder ... leaning-pc ) to find all of the files that contained "_b" (ie. all the bump maps) and copy them to a folder named LowRes. Then I used FastStone ( http://www.faststone.org/FSResizerDetail.htm ) and ran a batch convert for everything in that LowRes folder to bring the resolution down and saved it as a low quality .jpg and added a _LowRes tag to the end of the name.

As an extra step, whenever I'm creating or tweaking an arroway material now, I'll pop in it's LowRes version in an empty bump map slot and give it a value of .01 then set that LowRes image as the default image to show in the viewport. So now if I want to use that in SU, I'll just apply a random color to my object, link that color to my arroway material, and click the Copy Texture to SU Material button, and adjust the scale.

That's all a workaround to having an image proxy system and maybe overall doesn't necessarily save time but may be helpful to some folks. The biggest advantage is that it keeps everything in SU so you don't have to make tweaks to the maxwell file each time you export (I usually end up exporting my models a number of times as I do tests and as tweaks are made).

-Brodie