Offline
@thomthom said:
Sorry for being so dense, but I don't understand this at all.
What's the difference between:
ip = view.pickhelper ip.pick(x, y)and
ip = view.pickhelper(x, y)
Why are they not the same, and what would the use of
ip = view.pickhelper(x, y)be?
pickhelper(x,y) is a convenience. But you may want to create a pickhelper (which holds all the state) and then do a series of .pick(x,y) calls.
@thomthom said:
"Query Object"?
As in an object that encapsulates the query and all associated state into 1 handy 'thing'. It's a common pattern for picking / raytesting because you often want to make decisions about what your looking for as you walk through the results and don't necessarily want all answers/info - which can be large.
The point being its not a simple procedural call. Its returning a result which is a first class object on which you can operate to get the answer you want.
Adam
I think your looking at this a bit wrong..
When you create a pick_helper, you create a Query Object for that x,y. You can then extract a variety of information from it and then dispose of it.
Here's my attempt using image-based lighting AO and I made the windows area emitters.
First one is just linear AO, second is using skybox as emitter (IBL), third is with direct lighting as well.
Lighting time is 3 minutes.
@unknownuser said:
This thread is of interest to me. I design museum exhibits where lux / foot candles on the artifacts is very important to the curators. Is it possible to model LUX in an interior model based on the lighting in the exhibit gallery?
If it can, it means I could spec lighting fixtures in the design.
Yes, LightUp can produce Lux contour maps below in which there is a variety of IES light fittings being used:
That red spot has a reading of 780lx, whereas the others are a more reasonable 170-200lx
Adam
Yes, LightUp will give you amount of energy falling on the surface as well as a pseudo color image which can help quickly identify problem areas. You can get exact readings using the lightmeter inside LightUp.
It won't give you how much energy you need to make plants healthy.
So with a model like that, based in Boulder, CO on 1st December, the wall gets just 0.11 Kwh/meter/day:
whereas on 24th July, it gets 1.27 Kwh/meter/day:
@baz said:
Hello all,
Is it possible to get lux information from surfaces in a model with a ruby?
One of my clients builds Greenwalls (vertical gardens), and already finds my shadow studies useful, but if I could tell him how much light is actually hitting his plants it would make his job much easier and it would'nt hurt me either:)
Attached project is not a great example and never got past a feasibility study but it was surrounded by tall buildings and faced south so lux info could have been useful for plant selection. The client is doing quite a few interior installs where lux info is becoming essential.
I have no idea about the math involved in such a ruby, sounds complicated tho.
Too hard?
Baz[attachment=0:8iqmxi44]<!-- ia0 -->mail_general view.jpg<!-- ia0 -->[/attachment:8iqmxi44]
LightUp can do realtime spot measurements of lux as remus and thomthom said which is generally used for direct local lighting. LightUp can also full Insolation analysis which might be more what you want. Insolation calculation is based on both the geo-location you've set for the model and the time of year and gives kWh per square meter per day. This mode is useful for determining how effective self shadowing architectural features are working in keeping surfaces cool.
Adam
@jim said:
@tig said:
GC.start is Jim's baby - built-in - As I understand it you start if before making the groups ?
I thought I learned of it on this forum!
I don't think it's the GC that's slowing adding geometry - more likely it is Sketchup looking to make faces and break overlapping geometry as geometry is either added or exploded. (pure conjecture.)
Try this:
` def addfaces(ents = Sketchup.active_model.entities)
vertices = [Geom::Point3d.new(0,0,0), Geom::Point3d.new(1,0,0),Geom::Point3d.new(0,1,0)]
start = Time.new
1000.times do
ents.add_face vertices
end
puts "Same tris took #{(Time.new - start)}"
start = Time.new
1000.times do
ents.add_face vertices
vertices[0].z += 0.1
vertices[1].z += 0.1
vertices[2].z += 0.1
end
puts "different tris took #{(Time.new - start)}"
start = Time.new
1000.times do
ents.add_face vertices
vertices[0].z += 0.1
vertices[1].z += 0.1
vertices[2].z += 0.1
end
puts "more different tris took #{(Time.new - start)}"
end
addfaces`
Firstly adds 1000 triangles using the same coordinates, secondly adds 1000 triangles with unique vertices, lastly adds another 1000 triangles with unique vertices. Shows a 10x difference in performance, yet the geometry engine will be constructing the topology in all cases - ie doing work.
This would seem to indicate its an insertion bottleneck - which is consistent with thomthom findings.
What does it mean? It means its a brick wall and adding geometry in SU is slow and there is nothing you can do about it.
@tig said:
@thomthom said:
@tig said:
I meant
GC.startwhich collects garbage from group making etc...You use that after creating a group?
In my case here, it's creating geometry in a series of groups which is faster than adding all the geometry into the same context.
GC.startis Jim's baby - built-in - As I understand it you start if before making the groups ?
GC.start is Mr.Ruby's baby 
. It gets called automatically (every 256 instructions) by the Ruby interpreter and you generally don't need to call it yourself unless you really know what your doing.
@adamb said:
Adam, what is this COM interface?
Its a hateful, clunky and ultimately pointless way of calling C++ that was introduced by MS many years ago - and since largely abandoned in favour of regular OO solutions. My point isn't about COM, more about calling the SU API directly without using Ruby. AFAIK Google only provide a COM interface to their underlying C++ API.
@unknownuser said:
@adamb said:
You can get a ok approximation by doing the projection at the vertices and then interpolating across the polygon in 2d (this is what LightUp does), or you can interpolate the 3-element texture coordinate and do the divide at each pixel which is slower but you'll get the right answer. Not sure there are many renderers that do that.
SU is using OpenGL. Does it mean that SU, for its own 'rendering', does same interpolation and sends the 'unique' texture to OpenGL?
No, it means SU sends 3-component texture coordinates to OpenGL and allows OpenGL to interpolate and divide at each pixel.
But as Al says, given you can 'bake in' your projection to a unique texture once your happy, its not a big deal.
Adam
[Though Ruby's mark and sweep garbage collector is pretty ropey, its likely to be linear in time and probably account for a few percent of total execution time.]
I suspect the fundamental problem is that there is a method inside SU that is doing a linear search - ie start the beginning of a list and walk along until you find what you're looking for - and so the longer the list, the longer the time.
My 2 cents worth, I think Ruby is great for quick tweaks and scripting UI etc. But its simply not up for doing large amounts of "heavy lifting" - just too slow. I had a chance the other day of using Whaats ProfileBuilder; dead cool, but just insane delays as it builds geometry for each mouse click.
I'm coming to the conclusion that if you want to deal with whole models / large amounts of geometry, you really have to use the COM interface - unless I find out the 'linear search' is deep inside the SU proper... 
Oh, and the corollary of this is that if you subdivide the faces into smaller pieces, you'll get a progressively more accurate rendering. So try cutting the distorted quad into 16 quads.
Adam
Just a quick word as to what you're seeing.
The texture coordinates in SU are mostly 2d but there is support for projected textures in which the 3rd element of the texture coordinate is a projection. ie by dividing through by the 3 element you get a 2d texture coordinate.
You can get a ok approximation by doing the projection at the vertices and then interpolating across the polygon in 2d (this is what LightUp does), or you can interpolate the 3-element texture coordinate and do the divide at each pixel which is slower but you'll get the right answer. Not sure there are many renderers that do that.
Adam
Err, we're going around in circles here.
That snippet gives you all those instances that have visible?==true which is of zero use, since if the instance is inside something that is hidden, it too will be hidden.
The only way is to enumerate all instances then track back through the parts hierarchy for every instance - something the Ruby API cannot do.
But thanks for trying! 
The huge missing method in SU, is being able to walk up hierarchy.
Why I want to know, is I have a particular Component. I want to find all instances of that Component that are visible? Its essentially not possible without incredibly slow processing in SU.
@chrisglasier said:
@tig said:
B is visible inside A, but A is hidden so you can't see that !
Exactly. The original assertion was that it was plain wrong, but I think semantically it must be correct; whether it is inconvenient is another matter.
But thats my point. The meaning of the words "is visible" means to most people - "is this thing visible" and not "what is the value of some boolean inside the implementation".
Reminds me of asking a programmer "Have you got the time?" and he says "yes". Not useful.
Just got bitten by this behavior which for my money is just wrong.
ComponentInstance A contains 1 child ComponentInstance B
A.visible? => true
B.visible? => true
all fine so far, but if I hide A, you can't see A or any of its children.
A.visible? => false
B.visible? => true (Not a very useful answer..)
Really focussed on handling of large models for v1.7 - we're seeing huge performance increases on large models.
There's a free 30 day demo to download from the
website http://www.light-up.co.uk
And lets not forget LightUp which will do realtime Insolation analysis based on Geolocation and give Kwh/m^2/day for tracking and non-tracking surfaces.
Adam