I'm with Jim on this. Sounds a like a disaster to allow plugins to impose their view on how the GUI should work.

And if its just for something small - why do you not simply create your own toolbar for this? Then you can flash it on and off to your hearts content

Adam

Baking is a generic term used whenever you save out some data on a model.

In graphics, Baking can mean Lightmaps (like LightUp uses) or it can mean saving lighting to vertex colors (as you can do in Maya), or saving out skinned weights for an animation.

The general gist, is taking some 'ingredients' (aka parameters) and 'baking' (aka applying some process) that saves just the end result eg LightMaps, Vertex colors etc.

Adam

@mrwip said:

I'm sorry Adam, but that does not really respond to my questions.

So:
1_ Why does the AO parameters disappear from the menu when we're in 'direct sources' mode? Is it necessary to make first an occlusion pass, then a sun light calculation ?

Its hidden simply to reduce clutter from the GUI. In Direct mode, you can choose to blend in the results of any AO you have setup. LightUp will automatically generate this using your settings if it doesn't have this cached.

@mrwip said:

2_ Again, is there any way to adjust the shadow darkness (I didn't get so dark result with the previous version of lightUp)? ... Even with a white sky and ground, the interior in that model is almost black. I've try on other example, and sometimes I'm facing the same problem, sometime not, It's a bit random...

OK, I think the 'bit random' part is due to a glitch in the WebDialog Preferences. Essentially, it would set the Interior,Exterior,Custom choice to your previous choice.. which is obviously confusing and not what was intended. Get the fixed HTML file here.

Now you can choose Custom and increase/decrease the cutoff distance and you'll see the effect on your interior.

Adam

@mrwip said:

As you can see, the inside of the house remain more or less fully dark, even with a completely white environment (I've also try with a classic sky and ground, and the result is the same...).
Sun intensity does not seems to make much changes to the final result(I've try from 0.1 to 100. and it did not seems to make any big difference), and turbidity just add more yellow to the sun light (but that all we can ask to a turbidity slider...).

Ambient Occlusion should be effected by anything at any distance from the point being shaded. Sometimes this is what you want - typically for exterior models. However, with interiors and the like, almost all surfaces would be occluded if you traced far enough so most AO has a "cut-off" point beyond which the surface is considered "not occluded". This is just a practical tweak most renderers will offer - including LightUp.

LightUp has 3 settings for this "cutoff" distance:

Interior: Search for occluders within 10% of the model size
Exterior: Search for occluders within 100% of the model size (A 'perfect' AO calc)
Custom: Search an absolute distance for occluders.

If you have a large sized model (eg with a ground plane from Google Earth) then 10% of the size of the model will be huge compared to your actual house.
You need to specify an absolute distance beyond which you consider a surface to be 'Not occluded" by using Custom and entering the distance appropriate to the scale you've modeled your house.

Adam

Just FYI: The French version of LightUp is ready and I'll make it available soon.

@mrwip said:

There are still some issue like the fact that inside / close space are always really dark, without lamps... It's logical in a full radiosity program of course, but here with just an ambient occlusion calculation, there should be a way to adjust the shadow darkness / sky light intensity , just has sketchup does basically... I'm sure Adam will came with some explanations !

Ah, OK. So AO in LightUp works by calculating the occlusion at a point and then selecting a number of ways of coloring the result based on your selected mode in Preferences.
LU uses the Sky & Ground colors you've set in Sketchup Styles for Bright & Dark reference colors respectively. If you haven't checked Sky & Ground in Styles, LU will use Background color for Bright and Black for Dark instead.

Normal Mode: Use the Surface Normal to blend between Sketchup Sky & Ground color and change brightness using the AO result.

Linear Mode: Use the AO result to blend between Sketchup Sky & Ground color

IBL Mode; Use the bent Surface Normal to probe the HDRI and change brightness using the AO result.

Sounds like you want direct control over the shadow dark color and the sky light color so you'll be wanting to use "Linear" and set Sky & Ground colors.

Adam

@mrwip said:

kwistenbiebel , here are the presets used for this rendering :

[attachment=0:e2ucuoik]<!-- ia0 -->LightUp preferences.jpg<!-- ia0 -->[/attachment:e2ucuoik]
I'm using a simple HDR studio for the environment map on the buildings.

To share settings, you can use the new feature in LightUp v1.6 of Export/Import Preferences. Its a simple text file that holds all your settings for the current model which makes sharing preferences between people real easy.

You'll find it under the menu: Tools->LightUp

Adam

As has been discussed elsewhere on the forum, the WxSU plugins causes instability and crashes of Sketchup.

Different plugins keep different versions of WxSU inside their folder structure and there have been reports of Windows Search not being able to find the WxSU folders. The problem is users can be unaware they're loading a large amount of extra Ruby scripts that they're not using.

A sure fire way of finding where WxSU has been installed so you can remove it is to open the Ruby console and type:

WxSU.dir if defined?(WxSU)

If it prints 'nil' you're clear of WxSU, otherwise it will give you the path where its installed so you can remove it.

@tig said:

@adamb said:

@tig said:

@qverburg said:

Solved it with a Sketchup.send_action("selectSelectionTool:").

I end most of my complex tools with that....

I've always used Sketchup.active_model.tools.pop_tool so it returns to whatever you had before rather than forcing the use of SelectionTool.

Adam

But a lot of plugins end with you perhaps wanting to select something... or if I for example I have made a group you will want to move then I make it the model.selection and invoke the 'Move' tool...

Never ever ever second guess the user.

@clarryr said:

I am also looking at the reliability of the observer classes. So far I've found that the model passed to ModelObserver.onDeleteModel is wrong. When the model started I set model.name = "myname". On all the other methods I tested in ModelObserver I was able to see myname. Not so on onDeleteModel.
Larry

Yep. My understanding is that all delete methods are called after the fact. So the referenced object is toast by the time you are invoked.

Furthermore, I believe most problems caused by Observers is hanging onto stale references to Ruby objects that have been deleted. If you create null (do nothing) Observers, they are benign.

Adam

Yes. .to_s / .inspect print an approximation of the Float value. When it prints (0,1,0), thats just the answer to 4 significant figures. Your Float(1) comparison simply shows that difference.

@tig said:

@qverburg said:

Solved it with a Sketchup.send_action("selectSelectionTool:").

I end most of my complex tools with that....

I've always used Sketchup.active_model.tools.pop_tool so it returns to whatever you had before rather than forcing the use of SelectionTool.

Adam

If you open a new Sketchup document, LightUp automatically adds a new (good) Component Definition for PointLightSource. So open the Component Browser and you'll see it there.

Adam

@vizier said:

How do I reset everything? I seem to have set some materials to emitter status then forgotten which ones. I just want to start over.

You can choose the menu item Tools->LightUp->Remove All LightUp Info to strip all LU markup from your model.

@vizier said:

Also my point lights dont seem to do anything. THe emiitter works "ok" but the point lights never emit light. Any ideas?

If you hover over the PointLightSource with the Query tool, does it show the radius of light and a tooltip showing the lux power? If so, perhaps its just not powerful enough. LightUp uses physical units for lights so you'll need to ensure you don't have a 60 watt bulb in a room a mile wide etc.

Adam

Yeah, its a tricky one because you can check with respond_to? if it already exists but the semantics of the new method might be completely different.

I think extending the SU classes is a theological gray area / no-no.. as opposed to specialization through class derivation.

But I've done it a few times over the years. Most recently when I really want to be able to treat Selection just like a Model, so I added a bunch of methods that simply kick the message to Selection to self.model. It just made the rest of my code so much cleaner not having to constantly check what its dealing with.

Adam

[First off, thanks to TBD for forwarding the link to me..]

I never did really understand what it is you're trying to do, Chris, but the example TBD posted can be made to work by editing line 16 of sceneTest.rb to be:

cmd = "receiveSceneCount('#{count}')"

Guess they're not handling the (admittedly spurious) terminator correctly.

Adam

What is astonishing with FBX is that the "Hello World" test program comes in at 9MB executable. I just refused point blank to increase by 10x the size of my plugin by using this SDK. Its a joke.

FBX suffers from trying to be all things to all men so in order to write a full importer you'd be looking at a lot of work. Writing a simple importer that eats static hierarchical geometry and materials is straightforward.

Adam

Just for completeness, try hiding them in a hidden Layer.

I'm presuming its not "creating groups quickly" per se but the need to check every existing group for interaction with the new one that is taking time.

So if you have N groups in a flat hierarchy is it as slow as N groups in a deeply nested hierarchy (where SU can early out on these tests).

Adam

Have you tried (programmatically) hiding existing groups?

Adam

@thomthom said:

@adamb said:

Thats not going to work generally. What if I scaled by 2.0 in X, 5.0 in Y, and 8.0 in Z?

For the purpose if the RotaScale plugin - it's all uniformly scaled.

@adamb said:

Just forget the SU hack of storing stuff in t[15]. Overwrite it with 1.0..

I'm not that familiar with this transformation matrix. And I'm not sure if I understand what you're saying here. If I just override t[15] to 1.0 I loose all scaling.

Its meant to be 1.0 Its actually wrong not to be 1.0 but since the matrix is used for 3D and not 4D, they "get away with it".

@adamb said:

gives you the transform with all scaling removed but leaving the rotation.

I actually do want the scaling.

Aren't we going around in circles here? The blah.transform.to_a gets the correct transform for blah. I use it all the time in LightUp and it works fine. The only thing is, SU stores some uniform scale info in m[15]. If you want to apply this uniform scale then you could do:

m[0] = t.xaxis.length=m[15] ... ...

Perhaps its worth explaining that the scale of each axis is represented in the matrix as the length of the axis vector. So when you have X axis pointing along 1,0,0 and Y along 0,1,0 and Z along 0,0,1 then changing the length of those vectors becomes making those '1' the scale_factor, hence you'll see code that sets the diagonal of the matrix to scale_factor as Pixero suggested.

Adam

Whoa. Nice result!
And such an elegant model too.

BTW The next version of LU has a slightly different sunlight model which results in much bolder caustics.