Its all interesting info you're digging up thomthom, but I wonder where you're going..

Ruby is a scripting language that makes for very quick development, modern constructs and good readability. So you pay for that with execution performance. However, performance with a big P which may include how fast you can complete and deliver functionality may be better - but once again I do think you should play to Ruby's strength rather than perhaps bend it into something it isn't.

By the time you've created local copies of state, rewritten everything using a compact form etc etc you end up with something that is less readable and probably more prone to bugs. And as you've discovered, there is a massive difference in performance between native code and Ruby - such a large gulf, you're never going to come even close to closing it.

You should do heavy lifting with a C extension and GUI / API / semantic stuff with Ruby. Processing geometry topology with Ruby is, in general, not practical. Not that it can't be done..but that's not what I'm suggesting.

@jim said:

I guess to get back on topic, for loops are not faster then .each iterators. The performance must have to do with how the for loop variables are not loop scoped, as in each.

"Your racing car is not faster than my Trabant, it just covers more ground in a shorter time than my car."

@richard_ said:

Is there a way to keep a color from changing when orbiting?

In other words, for example, I have a object which is white (It clearly shows this from align view.)

But when I perform a orbit, the object changes from white to another color, grey, for example.

If I was to orbit in any other drection, the white, which turned grey, turns different shades of grey.

I want this object to remain white no matter a orbital direction.

Is there a way or metod to keep a object the same color, without changes like in shaded variables per performing orbit?

Thanking in advance for any repsonses,

Richard

Could be Z-fighting. But could be simply you've got the "Use Sun for shading" checked in Shadows dialog.

@solo said:

Khai wrote:

@unknownuser said:

more than GPU... the plan it seems is to combine CPU / GPU and Network Sharing into 1 seamless render option...

that will fly....

This 'Hybrid' model seems to be the next wave of render solution, Thea is also going this way, about time our GPU's got some action.

But its a complex trade-off. Because CPUs have much better flow control that GPUs so its easier to avoid doing work altogether.
For example LightUp is mostly CPU-based and performs around 1,000,000 samples / sec on the CPU side. Now you could imagine getting something going on the GPU that might be faster (and we plan to) but its very difficult to avoid doing work on GPUs. GPUs are built to execute a set of instructions in straight-line fashion - and they're spectacular at that - but sometimes working-smart can actually beat it.

I guess the pithy strap line is "The fastest ray is the one you never fire".

Generally No, because the underlying representations are different. (eg Integer in Ruby is actually an integer times 4)

Doubles are the exception as the representation in C and Ruby are the same IEEE format.

So the values can simply be copied. However the container is another matter; in C, arrays are little more than syntactic sugar, in Ruby an Array is a real live object, so you're kinda out luck.

The best you could do would be something like:

extern double *reals
extern int rcount;

static VALUE
method_getRealArray(VALUE rarray)
{
  if (rcount < RARRAY_LEN(rarray))
  {
    memcpy(RARRAY_PTR(rarray), reals, sizeof(double)* rcount);  
    return Qtrue;
 }
  else
  {
    return Qfalse;
  } 
}

@honoluludesktop said:

We need a program that will simplify mesh models of small things that are drawn with great care and accuracy. But guess that is off post:-), sorry.

For many many years people have struggled with this "level-of-detail" issue. There has been some great work done by Hugues Hoppe etc but ultimately its difficult to get satisfactory results because the shapes have "meaning" to us that the computer program doing the reduction simply don't understand.

In some sense, we've got this all back to front. We should be describing our models with the minimum information and then refine that description to get more details. Certainly when you get to the point of having sub-pixel polygons, you have to question whether this is such a great representation.

@honoluludesktop said:

AdamB, That's right about sound, then again (I am guessing that) if you have a mirror, with a thick exposed glass edge, with refraction, the behavior of light too is not that simple.

But thats the point. The wavelength of visible light is so small compared to the thickness of the mirror, the interference between the bounce from the back of the mirror and front is effectively zero.

Unless you have very thin mirrors!

[OT: Few years back I lifted the hinged door off an old french clothes cupboard to do something. The door had a mirror on it and must have weighed 50-60Kg. I staggered over to the bed and dropped it on the bedcovers and noticed the mirror had tiny flecks of mercury oozing out. The whole mirror was constructed by sandwiching mercury between glass!]

@thomthom said:

Yea - I used to create tools every time it was activated as well - due to the examples in the manual always do so. Can't remember if it was Fredo or Whaat that mentioned it was not necessary.

Well Dan is sensible guy who says smart stuff. But I'm not quite sure why you want to keep a reference to the Tool around rather than release it back to the system. The specific reason I generally keep dialogs as class variables is to avoid the weird GC behaviour I wrote about earlier. But the rule of thumb in OO systems, is you create stuff, use it and explicit/implicit release stuff.

The exception is sometimes performance when you pre-create Pools of objects to use/share. But this isn't one of those cases.

Adam

@unknownuser said:

Does this accoustic ray takes the same way than the way for a ray tracer "light"?

"Not really" is the answer. I looked into this when we were trying to design a new 3d audio system in a previous life.

So for light (MHz), the frequency is so high that diffraction / diffusion effects can be ignored. It moves in straight lines.

But for sounds (kHz) , edges/corners/gaps have huge effects. Hence you can hear somebody speaking when they're around a corner!

Moreover, the lower frequencies are going to spread around corners more than the higher frequencies components so what you hear will be different too. And just to make it even more complex, the substance of the building transmits sound - so if you're in the next room and listening to something, you may get high frequencies components coming out the door of one room into the door of the other while the low frequencies come through the wall.

@unknownuser said:

I have done it other way round. I was keeping a WebDialog as an instance variable in my Tool class. Now when the WebDialog governs the Tool it works much better. Thanks Dan!

What if I a tool is being cancelled. I want to close the associated myDlg with the onCancel(reason,view) method in the tool. But if I will do that I will triger on_close in the webdialog which will destroy the tool. Am I right?

> class MyTool
> 
> def initialize(myDlg)
>   @dlg=myDlg
> end
> 
> def onCancel(reason,view)
>   @dlg.close
>   #Will not return here because the tool doesn't exits now
> end
> 
> 
> 

Have a read of this link I posted last year regarding WebDialogs and Tools.

Its a bug though. Introduced in the last couple of version of SU. I posted a bug to Google sometime back.

Previous to that, you could use drawing_color (as expected) to control text color.

no

@pixero said:

@unknownuser said:

@pixero said:

Anyone but me who gets a wxSU warning/error upon SU launch?
It warns about possible problems with other plugins like LightUp.

Can you post exact message, please?
SU-2-Thea uses WxSU 0.3 version in which interaction issues with other software has been resolved.

Here it is.
Maybe it's LightUp's own wxSU warning?

You can disable LightUp warnings like this by opening the Ruby Console and typing:

Sketchup.write_default("LightUp", "Warnings", false)

But be aware that currently WxSU does have fundamental problems working with other plugins.

@unknownuser said:

@adamb said:

I tried to get the author of WxSU to address the issue but didn't anywhere and got tired of endless support of LightUp regarding this issue.

Thanks Adam for the explanation. I am in contact with Peter and hope to have the 'sleep' issue resolved soon.

Well good luck..

I just downloaded your installer to check the WxSU version and ensure I'm not just becoming grumpy in my old age, and indeed WxSU still has this special code in "App.rb":

    # This is the main entry point to the WxSU;;App object.  This method performs some thread kludges 
    # so that wxRuby and SketchUp play well together.
    # After creating an App object with 'new', call 'start' to initiate wxRuby.
    # For example;
    #   WxSU;;App.new.start
    def start
      if (not is_main_loop_running)
        @thread = Thread.new { main_loop }
        @thread.priority = -1  # Kludge to lower the priority of wx; seems to work really well
      end
      return(self)
    end

Now wash your hands.

@unknownuser said:

I think it is unfair. Do you have latest LightUp version installed?
Please notify me if you experience problems with LightUp while having WxSU 0.3 installed. This message must be annoying to you. Does it show up every SU start?

I also hope Adam will test the SU-2-Thea plugin and revise his opinion or help me to resolve any potential problems.

This is about WxSU not playing well with SketchUp. Its not about SU-2-Thea per se - though I appreciate if you've built on WxSU, you'll run into this.

The problem is WxSU does some truly heinous hacks of Ruby to work under SketchUp. Specifically, it tries to hide the problem by lowering the priority of the thread in an attempt to make sure it doesn't run.. Firstly this is a shit solution. Secondly, as soon as somebody sleeps, the thread will be scheduled and if you've not got a WxSU window open, it just breaks.

I tried to get the author of WxSU to address the issue but didn't anywhere and got tired of endless support of LightUp regarding this issue.

@chris fullmer said:

well now that is odd! NaN does not compare equal to itself essentially? or is it something else?

So its a really useful side-effect. You can have a line in your code:

if (a != a)
puts "its all gone pear-shaped"
end

for debugging.

Correct! IEEE NaN is defined as always failing comparison.

Or in Ruby:

a = 1.0 / 0 b = a - a b == b

Quiz time for all you old school badass coders:

When is the comparison "c == c" false?

@jhauswirth said:

There's no limit (at least in the code).
RAM and HD space would be the limits.

Might sound like a silly question. But are you certain of that?

I believe there is a buffer overrun somewhere if you have large data attached as attributes somewhere in the handling of it inside Sketchup.

LightUp stores Lempel-Ziff compressed hex strings on entities and by trial and error, I came to the conclusion anything larger than 700000 bytes kills Sketchup. So I split up data into <700000 char chunks it works fine.

I think there is something wrong with the draw calls inside Sketchup. I've logged a bug with Google as if you do a glGetError() afterward it returns "over/underflowing matrix stack" like they've popped once too often.