Just open the file from Ruby and rip out what you want, whats the problem?

@thomthom said:

@adamb said:

LightUp has gone the way of animated textures using movie "strips"

Not video files, but images with all the frames in a series?

Exactly. So its not a solution for watching "Gone with the Wind", but for adding a little dynamism like underwater caustics, fires, flames etc, it works very nicely.

Its stored in "doc_thumbnail.png" in the SKM file.

But can we see you "throwing a fit" for entertainment value?

LightUp has gone the way of animated textures using movie "strips" which works pretty well. I've attached an example SKP file.

And here an old vid using the same animated candle movie strip:
[flash=400,300:ha5vn9dc]http://vimeo.com/moogaloop.swf?clip_id=4710188[/flash:ha5vn9dc]

candleflame.skp

@wind-borne said:

Initially, I will be looking at Lux for estimates of losses due to shading as program does face calculation if I understand the static reading.

LightUp Insolation rendering gives 3 readings:

1. A spot Kwh/m^2/day for the exact position from which you're taking the reading.
2. (Static) A Face reading of Kwh/day (ie scaled by the area of the face). This is useful if you model panels with a single face.
3. (Tracked) A Face reading of Kwh/day assuming the face tracks the sun (and is therefore more efficient).

Adam

Cool.

At the risk of stating the obvious, the energy falling on a surface (available energy) will be much larger than what you can actually produce - as is born out by the measurements you show.

Short answer: Yes, within the limits of the insolation model used. Essentially the interaction in the atmosphere are so complex that researchers have produced numerous models that try and capture essence of the issue without going nuts. Its a surprisingly tricky subject.

Long answer: LightUp insolation calculations use the Kasten & Young variable airmass model based on a nominal 1366 Joule/sec. In reality the amount of absorption due to the atmosphere varies with the cloud cover / haze which is represented in by a "coefficient of extinction". 0.1 would be a super clear non-hazy day. 0.8 would be overcast day. 0.5 represents some middle ground representing absorption and reflection in the atmosphere as the sunlight passes through to the ground.

LightUp takes account of geo-location in determining daily insolation and the Kasten & Young model does a good job at modelling the curvature of the Earth and thus sunlight passing through a larger "slice" of atmosphere. And of course LightUp itself occludes the sunlight using your model over a 24 hour period. Together these give a good estimation of available energy on a surface - significantly better than the very broad rules of thumb you'll find in many solar energy modelling packages.

So the Extinction coefficient is something that needs tweaking to reflect the general expected weather for your location, but it is more a fine adjustment. The general picture you'll get with leaving it 0.5 should be fine.

Adam

@driven said:

Hi Adam,

are the GPU enhancements card specific?

Basically are they going to be there, on my Mac, when I can clear some time/space to do a proper trial,

No, they're not card specific. It will work on any modern OpenGL card - Mac or Windows. In some ways the question is how far to the low-end to support rather than Mac or Windows which cause few problems.

@driven said:

I ran out of time by installing when too busy on the last demo release, so I want to finish this texture mover ruby first.

I do think LightUp is the most promising Mac/SU combo, keep up the good work, and try and keep it Mac friendly...

john

Will do. Given the development is probably even split between Mac & Windows, I'd be interested in any feedback where you think its not Mac friendly.

Thomthom, what do you actually want?

If you don't need the full DOM, then these big (often slow) XML parsers may be a hammer to crack a nut.

If you're just looking to use XML as a simple text mark-up of parameters etc, then writing something in Ruby that yanks out tag-value pairs would be trivial.

@thomthom said:

Only way is to map the whole model, going from Model and up. Which is just a brute force way to do it.

Not really true. Its certainly non-trivial but LightUp does it . ie LightUp needs to find the transform of every instance of a Component called PointLightSource. Clearly starting at the top and walking down is "one way" buts its incredibly inefficient. Better is to get each instance (trivial) then work your way back up concatenating transforms as you go - and dealing with the fact that there can be many instances of Components as thomthom points out. Took a fair amount of head scratching but its all in lightcache.rb if you want to take a butchers.

Its invoked by list = LightCache.flat(LightCache.walk(ent, ent.transformation)) which gives you back a list of transforms.

Adam

If thats what Sir wants.

@martinrinehart said:

Sounds complicated. How about:

` center = face.bounds.center
edge1 = camera.eye to center
edge2 = camera.eye to (center + face.normal)

edge1 longerThan edge2 ? outside : inside`

This fails in the special case when camera's line-of-sight is nearly parallel to face's plane.

But thats much more work than a dot product. Your turning an orientation problem into something its not.

There is a new version of LightUp available (v1.8) that introduces the first in a series of GPU-based features.

Specifically, once the render is complete you can adjust Exposure, Contrast, Saturation and Temperature all inside SketchUp during realtime navigation. It works really well for tweaking images without having to redo the rendering.

Also realtime Bloom can be adjusted to control the softness of the image.

Website: http://www.light-up.co.uk

Feedback always welcome.

@thomthom said:

But how would different plugins wanting to implement this handle this? multiple plugins extending the layer class?

So I'm simply going to conditionally add some methods if they're not already there. Because I can't return the material in any useful way, I'll collapse the method calling sequence into 1 name. So:

Sketchup.active_model.active_layer.material_color

Sketchup.active_model.active_layer.material_texture

Adam

Just a little update.

I've written an extension to extract the Layer material by adding an extra method to class Layer. Works great.

The interesting thing is that the Layer Materials all have names too (starting with "Layer_") but they're invisible to the Ruby material list so I can't return a reference to the Ruby material. I have to return the color and/or texture.

When I get a mo, I'll package it up and post it.

Adam

FWIW LightUp does this:

pickface.normal.transform(@xform).dot(view.pickray(x, y)[1]) > 0

@pg09 said:

And yes it would be a dream come through if this plugin not only would show the problematic textures but would also fix them per click )maybe offer 2-3 lower res options...
That sounds complicated to program though but what do i know...

Easy enough to do but Goldilocks shows you the density for a specific viewpoint. If you change the view and zoom in closer, the texture that was too detailed before, is now OK. So probably best to just highlight potential problems.

I had a model the other day from somebody which was incredibly slow - turned out 1 texture was 12000 x 10000 pixels. Just the act of Sketchup shrinking it took 1.6Gb on my Mac

Adam

@minguinhirigue said:

Adam, is it possible to extract some insulation numerical values (eg : on a desk) after the calculation ? I would like to use it in a lighting optimization script.

Yes, in that you can call the LightUp functions from Ruby to generate "spot" results at locations you choose. ( view.spotlux(x,y)) but really we should have a proper report generating framework.

What kind of information / format are you looking for?

Adam

OK thanks. So I'm not going mad!

Adam

Is there any way of retrieving the Layer material if rendering_options['DisplayColorByLayer'] has been set?

I can't find anything..

Adam