[Code] Raytest Util
-
Thanks for these well-designed and documented code examples!
The raytest is so much more useful when used in a loop (ie. for finding an entity in for example vertical direction). -
Thanks guys
I improved Ruby in some, changed documentation to Yard, and added raytest_t3 which passes through transparent faces and stops until it hits a solid face. See first post...
-
Does anyone know how raytest is implemented? Does SketchUp use a BSP or some other data structure to speed up geometry searches?
In other words, is raytest reasonably fast or is it done in a brute-force manner? -
I have no idea, but it doesn't seem fast to me...
-
It's fast enough for what it was designed for - which is casting some rays into your model to orient/locate GUI elements.
No, it is not suitable for raytracing etc where you'll be casting millions of rays.
Yes, it uses a spatial structure to accelerate queries.
-
Thanks!
@adamb said:
No, it is not suitable for raytracing etc where you'll be casting millions of rays.
That's too bad, since this could be useful.
-
Just did a very quick'n'dirty test between Ruby raytest and LightUp raytest and its not terrible under SU2014.
Raycasting a simple scene:
Ruby: ~250,000 rays/sec
LightUp: ~2,000,000 rays/sec (but in real usage its multi-threaded so more like 10,000,000 rays/sec) -
@oricatmos said:
That's too bad, since this could be useful.
If you are curious about raytracing, take a look at this script based on Adam's raytracer. The preview took about 3/4 hour.
I really see no advantage of having an imperfect built-in (or Ruby plugin) raytracer, while there are already so many dedicated renderers with better illumination models, more speed and more realistic output. -
@aerilius said:
I really see no advantage of having an imperfect built-in (or Ruby plugin) raytracer, while there are already so many dedicated renderers with better illumination models, more speed and more realistic output.
Yeah, I guess the raytest function would need to be able to take an array of rays and do multithreaded casting to be comparable to an external raytracer. By the way, we're doing room acoustics simulation, not visual rendering, with our plugin.
-
@aerilius said:
I really see no advantage of having an imperfect built-in (or Ruby plugin) raytracer, while there are already so many dedicated renderers with better illumination models, more speed and more realistic output.
Well, raytracing can be used to so many different things than rendering.
-
Coming back to the main topic...
I've got a 20% gain in speed by using hashes lookups instead of arrays.
<span class="syntaxdefault">ents </span><span class="syntaxkeyword">=</span><span class="syntaxdefault"> </span><span class="syntaxkeyword">[</span><span class="syntaxdefault">ents</span><span class="syntaxkeyword">]</span><span class="syntaxdefault"> unless ents</span><span class="syntaxkeyword">.</span><span class="syntaxdefault">is_a</span><span class="syntaxkeyword">?(Array)<br /></span><span class="syntaxdefault">entIDs </span><span class="syntaxkeyword">=</span><span class="syntaxdefault"> Hash</span><span class="syntaxkeyword">[</span><span class="syntaxdefault">ents</span><span class="syntaxkeyword">.</span><span class="syntaxdefault">map </span><span class="syntaxkeyword">{|</span><span class="syntaxdefault">e</span><span class="syntaxkeyword">|</span><span class="syntaxdefault"> </span><span class="syntaxkeyword">[</span><span class="syntaxdefault">e</span><span class="syntaxkeyword">.</span><span class="syntaxdefault">entityID</span><span class="syntaxkeyword">,</span><span class="syntaxdefault"> 1</span><span class="syntaxkeyword">]}]<br /><br /></span><span class="syntaxcomment">#...<br /><br /></span><span class="syntaxdefault">entID </span><span class="syntaxkeyword">=</span><span class="syntaxdefault"> hit</span><span class="syntaxkeyword">[</span><span class="syntaxdefault">1</span><span class="syntaxkeyword">][</span><span class="syntaxdefault">0</span><span class="syntaxkeyword">].</span><span class="syntaxdefault">entityID if hit</span><span class="syntaxkeyword">[</span><span class="syntaxdefault">1</span><span class="syntaxkeyword">][</span><span class="syntaxdefault">0</span><span class="syntaxkeyword">]<br /></span><span class="syntaxdefault">return result if entIDs</span><span class="syntaxkeyword">[</span><span class="syntaxdefault">entID</span><span class="syntaxkeyword">]</span><span class="syntaxdefault"></span> -
@jiminy-billy-bob said:
Coming back to the main topic...
I've got a 20% gain?
I never thought Hashes were faster than Arrays.
I will edit the code above. -
@oricatmos said:
@aerilius said:
I really see no advantage of having an imperfect built-in (or Ruby plugin) raytracer, while there are already so many dedicated renderers with better illumination models, more speed and more realistic output.
Yeah, I guess the raytest function would need to be able to take an array of rays and do multithreaded casting to be comparable to an external raytracer. By the way, we're doing room acoustics simulation, not visual rendering, with our plugin.
The wavelength of light is small so mostly you can ignore diffraction effects and treat light as moving in straight lines. Audio wavelengths are much longer and have significant diffraction around corners (hence you can hear round corners!), so how does using (straight line) raytracing help here?
Just interested..
Adam
-
@anton_s said:
I never thought Hashes were faster than Arrays.
I will edit the code above.This is because in this exemple, we look for keys in the hash, compared to looking for values in the array.
I guess they're as fast as each other in both cases, but in hashes you can have custom keys. -
@anton_s said:
I never thought Hashes were faster than Arrays.
Ruby saves developers from using primitive data types how data is stored in RAM, but it has more abstract, optimized data types.
Arrays are likely implemented as a double linked list (correct my if I'm wrong) and hashes as some sort of trees. You can see in Wikipedia what each of them are good at (see indexing). -
Howbout Array.uniq! ?
-
@aerilius said:
@anton_s said:
I never thought Hashes were faster than Arrays.
Ruby saves developers from using primitive data types how data is stored in RAM, but it has more abstract, optimized data types.
Arrays are likely implemented as a double linked list (correct my if I'm wrong) and hashes as some sort of trees. You can see in Wikipedia what each of them are good at (see indexing).Ruby Arrays are simply contiguous sequences of VALUES - no linked lists here.
Hashes are just Arrays - just not using an integer index to access but the digest of an arbitrary "Key".
So a bit like:array["my key string".hash] = a_value array[123.hash] = a_valueHash tables take care of the generated key being larger than the array (aka Table) and also collisions (2 keys generating the same hash) - but essentially its just an array.
Hash tables have no "ordering" - its a Set or more properly a Collection since Values are not unique.
Aerilius, you may be thinking of Ordered-collections which can be implemented using a tree (red-black trees being a common example).
-
Another way of thinking about it is that Arrays are actually Hash tables using a really simple hashing algorithm that is:
hash(N) => N
Have a good weekend!
-
@adamb said:
The wavelength of light is small so mostly you can ignore diffraction effects and treat light as moving in straight lines. Audio wavelengths are much longer and have significant diffraction around corners (hence you can hear round corners!), so how does using (straight line) raytracing help here?
Good observation! Raytracing is essentially just an approximation of how sound travels. Diffraction can't be modeled that way. As far as I know, simulating diffraction is still a hot topic in the field of acoustics and there's no catch-all automatic solution yet. (I'm not an expert in acoustics, I'm just a Computer Science student doing some coding at an acoustics chair/institute)
-
I've been playing with raytest a bit. From my understanding, it works like this:
- It checks ALL entities in the model root context
- If something is hit and it's a face/edge/etc, the raytest returns the entity
- If the hit entity is a group or component, it again checks ALL entities in that group/comp
- And so forth until it hits a face/edge/etc
So if you have a lot of loose geometry in one of the hit contexts, it will be damn slow. But you can have a shitload of geometry in a group/comp not on the path of the ray, and you'll have decent performances.
To check if a group/comp is hit, the raytest doesn't look at the geometry inside it, but rather at its bounding box.
This is really important because you could have a lot of geometry away from the ray, but if the bounding box of the containing group is on the ray path, all of that geometry will be checked. Resulting in a slow raytest.I hope it's clear?
Advertisement