FWIW, if you really don't want them to get their hands on your model, then you need to convert the model to another form which simply does not contain the primary content (so it cant be recovered).

So, perhaps convert it into a movie, an interactive sequence of images of the model rotated (a la 3dwarehouse) , etc etc.

Adding degenerates / zero-area geometry / component-per-face simply degrades their experience of your work.. which probably isn't good for business!

Adam

No, because as (I think you thomthom) discovered "All tools are equal, but some Tools are more equal than others" so there are Ruby tools which we mortals get to play with and extend and then there appears to be "Native code" tools that only those in swishy robes and working Boulder can play with.

And ultimately, its breaking the metaphor that we're being provided with. That of a sequence of: tool selection, tool use, tool disposal. The slight wrinkle introduced for the sake of usability in all this is the suspend/resume protocol in which the Orbit tool can be "semi-invoked" and then you return to the original tool.

If you're going to turn it into a "feat of engineering" and beat it into submission then I guess you could hook the OpenGL updates somehow and slip in your commands just before the glFinish() - but at that point its just that - "a feat of engineering".

I should explain. The Ruby in SU isn't just a Ruby interpreter included in the package - in the same way as newLISP is an interpreter. The Ruby you get in SU is integrated into SU, so SU data structures appear as first class objects in Ruby. Without this, there is just not a lot you can do with newLISP. Sure, you can create some strings that you can pass to Ruby but you get no advantage to running newLISP in the SU environment compared to running outside and writing to a file.

But ultimately, you're right, if you find it useful for your work, knock yourself out.

Adam

No

Am I missing something here? If it has no bindings to the underlying SU objects, whats the point?

My 2 cents worth..

I get the strong sense you're being distracted from your core task...this is a "Displacement activity" to avoid focussing on what you really should be doing..

Doing a walkthrough with DCs for interaction using just Sketchup is completely do-able; I suggest you focus on getting that right rather than playing about with game engines..

Adam

@ecuadorian said:

I remember this movie. I specially remember how they demonstrated that tic-tac-toe is an absurd game.

I want to see your other vimeo videos (Specially the "lightup killer future" one) but the embedded player will not let me... Could you please post a link to your channel?

301 Moved Permanently

(www.vimeo.com)

But it really doesn't come out well on video. Since you have LightUp, you can start Tourtool, open the Ruby console and type:

LMapExt.ascii true

And now navigate in glorious ASCII!

I came across this pic from War Games.

and thought it might be fun to model it in Sketchup. Definitely a WIP but brings back happy halycon days.
[flash=420,350:gf8wqixd]http://vimeo.com/moogaloop.swf?clip_id=3867765[/flash:gf8wqixd]

I've done a version of Quake running in LightUp.. "SU-Quake".. the way of the future!

I actually use DCs for all the moving doors/elevators etc. It is kinda spooky running around those levels inside Sketchup.

Adam

First off, "Volume Calculator" is TIG's baby not mine!

The analytic method for Volume calc (the fast one) will not give the right answer if you have "open geometry". You can find all open edges by running a script like this (doesn't recurse into groups/components):

def findleaks(ents = Sketchup.active_model.entities)

	for ent in ents 
		next unless ent.kind_of? Sketchup;;Edge
		
		if ent.faces.length == 1
			Sketchup.active_model.selection.add ent
		end
	end
end

The problem is there isn't a real simple way of automatically closing those "leaks".

Adam

BTW Thats "cube root" not "3 times squareroot"

Perhaps TIG could be persuaded to add a function to Volume Calc that does this since I can see it must be pretty common to be wanting to get to a target volume.

Now if three men take four days to dig.. nevermind..

Adam

@talig said:

Jim - Thanks.
I'm using raytest. But I need a fine-grain detail.
See, if I have a component - raytest will return the component as an answer for the ray hitting any of it's faces. I need to know which face in that component was intersected. More accurately, I need to know that a certain face that should have been intersected, isn't - because it's shaded.

Thomthom - any thoughts?

Thanks again guys,

• Tali

So I've been lurking on this thread and the bit I don't understand is that Model#raytest does return the Face you pick (along with the Component/Group parts hierarchy). Isn't that what you want?

@unknownuser said:

is there any way to force a volume, i have a bottle design here and the client needs it to be 500ml and wants to know what the resulting dimensions would be.

If you know the current volume with the current dimensions, then you'll need to scale the current design by:

3√(targetvolume / currentvolume)

Adam

@jackson said:

So what factor affects the otherwise random positioning? It would seem to me the only factors which could cause this obviously non-random influence on random scattering must be either
a) proximity to the centre point
b) proximity from the boundary

Its a bit involved but since you ask...

If you use a random number generator that is normally distributed and use it in an orthogonal linear space you're all set. So compo_spray along a Line works great with no bunching. But for the Spray mode, the script calculates a random radius and a random angle around the center. However, the circumference of a circle close to the center is smaller than at the outside edge of the spray so using a normally distributed random number for the radius effectively biases position generation to the center point of the spray.

Adding "clash-detection" means you can set a "N per unit area" threshold so although it tries to add more near the center of the spray, they get rejected hence you don't get that bunching.

Phew....Fascinating, huh?

@honoluludesktop said:

How about some help with this. I know little about Podium, and next to nothing about LightUp. The programs selected cost more then nothing, but less then half of SU Pro. While they have many other render functions, the following items were selected to distinguish between them. In other words if all of the programs have a given function, that function was not included.

Please suggest functions, and indicate which programs have it. Also evaluate, and correct attached items. The list will be updated from time to time.

I think its a bit of an Apples 'n' Oranges comparison, however for LightUp:

Bump Image: Yes
Bump Slider: Yes
Explode before render: No
Light fixture invisible: Yes
Area Light: Yes
Multi processor: Yes
Render group / component materials: Yes
Render with SU sky: Yes (used as IBL source)
Render with SU ground: Yes (used as IBL source)
Specify render size: Yes
SU textures: Yes
SU view as final render scene: Yes
Sun image: Yes

Cool plugin, Didier. I really believe these kind of 'smart' tools are the way forward.

Jackson: The "bunching" in the middle is caused by the way the random positions are calculated.

Just as an experiment I added some 'clash detection' to the plugin. The idea being before it adds the instance it checks there is space for it. It really reduces the overlap of Component instances (obviously) but also helps the "bunching" in the middle because it avoids adding too many near the middle.

[I didn't want to make big changes to Didier's baby, so it only catches most clashes - with more work it could be made to never add overlapping Components]

Adam

PS Didier, I'll send you my changes. Ignore / use / abuse or whatever as you see fit.

[Hey thanks Mike for posting that Announcement for LightUp v1.4]

Yes, the website was down for a few hours partly due to a lot of people downloading.

Its now back up and you should be able to get the latest version.

@ecuadorian said:

Another lil' test, this time with a model from the Google 3D Warehouse. I have the feeling that LightUp is better suited for cars, robots and other shiny things. The less flat faces your model has, the better it looks when you apply specularity in LightUp.

Cool vid. It may be my internet connection but the video won't play smoothly for me yet I know LightUp records movies at 30Hz.

@tgb57781 said:

The Great Wall!
I love it.

Totally cool movie. Did you use the Image-based lighting to get the shading like that?

Adam

Mea culpa

AABB = Axis aligned Bounding box (blue box)

OBB = Oriented Bounding box (red box)

I've found it to be a "theological gray area"!

Because if you have an observer on an object there is an argument that this is a reference and therefore the observee is going to hang around and not be GCed. Let alone the Observer proper.

As a general rule for Ruby programming - particularly for SU where the Ruby objects are essentially proxies - if you have the opportunity to break references, do so.

Adam

The bounds method gives you an AABB not an OBB, so it is expected behavior that it will be 'fat' when your object is rotated to be not aligned with the XYZ axes.

ie There is a difference between taking the BB in local space and transforming those (8) points into world space compared to transforming the object into world space and determining the BB (which is what SU does).

Move along..

Adam