Model.raytest broken in SU8!
-
Thanks Thomas for your efforts! I hope it will be a fix with a high priority.
-
I just found that my workaround isn't perfect. I still have cases with rays straying away. -
` cl=sel[0]
#Sketchup::ConstructionLine:0x18b6e6a4
r = model.raytest( [cl.start, cl.end] )
[Point3d(0, 0, 0), [#Sketchup::ConstructionPoint:0x18903324]]`It doesn't hit any of the model axis planes, but yet it returns ORIGIN and a CPoint. I don't know how to work around this one. Can't find the trigger.
-
@thomthom said:
@daiku said:
I can confirm that this bug has broken my scripts as well. I add cpoints based on where the ray interects with a face, and the points get added "out in the weeds", not on the face. CB.
If you cache the points for where you place the CPoints until after you have done all the raytracing, does it work then? (Ensuring there are no CPoints in current context before you start)
Unfortunately, there are CPoints already in the current context when I try to preform the raytest.
-
@daiku said:
Unfortunately, there are CPoints already in the current context when I try to preform the raytest.
Yea - I'm having the same problem. Trying to find a workaround that doesn't involve grouping the CPoints before processing.
-
Lads, this needs to be fixed on SU Team level urgently! Looking for a workaround is desired, but why we developers have to fix something that is wrong on C++ level, not in Ruby!
Do you expect new maintenance release in the end of 2011? -
@unknownuser said:
Lads, this needs to be fixed on SU Team level urgently! Looking for a workaround is desired, but why we developers have to fix something that is wrong on C++ level, not in Ruby!
Do you expect new maintenance release in the end of 2011?Agreed. Has anyone reported it, or gotten confirmation from Google? IIRC, there were some bugs in SU7 that were corrected fairly quickly. CB.
-
I've reported it, and nagged nearly every day. It's being looked into.
-
And I was thinking it's just me.
I found the problem in a different way, but it's still the same one.
In my case it seems raytest is broken by any 2D text added to the model, raytest will work normaly for some directions and hit the text in others(I assume that was the passing axis plane issue), and once I tried hidding the text before raytesting (so it would ignore it) I instantly got a bugsplat.Anyway, removing all 2D text is a solution for that.
-
@unknownuser said:
Lads, this needs to be fixed on SU Team level urgently! Looking for a workaround is desired, but why we developers have to fix something that is wrong on C++ level, not in Ruby!
Do you expect new maintenance release in the end of 2011?Agreed!!!
--
Karen -
I Downloaded "SU8-raytest-bug.skp",opened it in SU8M2, and in the Ruby console, with the same consept wrote
model.raytest("construction point position", "vector of construction line")and it worked right; returned the right intersetion point, the right face and group.So, is this bug already fixed?>
-
Ah, yes! It's been fixed. I'd forgotten about this thread.
-
Strange this recurs...
Raytest IS fixed...
Sort of - BUT it can still be flaky !I'm doing some code for a tool at the moment that adds instances inside a 'group' at set xyz spacings.
If it were a cube it's easy enough to ensure all of the added instances are wholly within the groups enclosing faces by using maths.
However, if for example the group has a sloping 'roof' face then there must be fewer instances inserted in the 'z' at the 'eaves' that at the 'ridge'.
To do this I add the instances progressively upwards and then use
rayt=model.raytest([possible_insertion_point, Z_AXIS], true)***
and
if NOT rayt I know it's outside of the group
but if rayt then I check it to see
if rayt[1].include?(group)
if NOT I know it's outside of the group***
if so it's probably inside the group...
however, it would be possible to have an 'overhang' or 'notch' in the form which then puts the 'possible_insertion_point' outside of the group, BUT rayt will return wrobgly- so the next test is
if rayt[1][-1].class==Sketchup::Face
and
if so rayt[1][-1].normal.z<0
as this is hitting a downward facing surface, so the tested-point is outside of the group's 'skin', but below part of the group, and therefore giving a false positive...OK... so this works fine most of the time... BUT now and again it misses and returns rayt==nil when it clearly is 'inside' the skin and it should return an array [confirmed by adding cpoints at the tested-points when NOT rayt]. I can't see why this is occurring at all.
***Also the 'true' optional second argument is flawed sometimes.
If I have objects inside the group that I either hide OR put on an OFF layer temporarily, then they do not interfere with the rayt... usually!
BUT now and again the rayt will fail for some test-points that overlap with this hidden object [returning nil when it is clearly inside the group] BUT unexpectedly work correctly for others overlapping points - but it never returns the hidden object, just 'nil'.I'm trying to resolve all of this, as it is vital to the operation of my new tool !
-
You have a test case?
-
No, because it's part of a larger code set...
Since writing I have found a 'cause'...
Because the tool is doing solid intersections etc to avoid small facet errors on smaller objects and 'non-solidity' in results the objects are scaled up 100, then processed and then scaled down 1/100.
All other objects are auto-hidden/restored too.
When the raytesting is done the object is already scaled up, so the tested point is 'scaled' so it's then inside a hidden neighboring object. Having that object hidden does prevent most of the false positives BUT occasionally one or two incorrect results occur - it's hard to reproduce.To avoid this I am now recoding so that the scaling up occurs after the instances are added but before the solid intersections etc - I hope this will avoid the issue - watch this space...
-
Okay, so Thomthom says its fixed and TIG has some conserns
...well, I never had any issues with raytest, though, I guess I'll note, if discover any.Anyways, the bellow question is a bit off topic, but to make sure:
Lets, say I write Two of my own simplified raytest functions (similar to
Raytest 2). One on C++ (raytest2cpp), compile it to .dll, and extern it into some of my Ruby module using dl. The other, on Ruby (raytest2rb). On SU, which of these will work faster, why, and approximately by how much percent faster? -
To recap...
In v8M2 model.raytest([point, vector], true) will work [relatively faultlessly].
BUT if you have scaled objects then raytesting can be flaky and sometimes returns nil in areas where it should return a hit, IF the ray passes through space occupied by a hidden object [which of course it should ignore!] - moral = do not scale an object and raytest within it...
I'm removed the scaling from the raytest code loop and it now works faultlessly, so far... -
Hi,
A little bit off topic but I'm using raytest to check if a ComponentInstance is on a face or not. I shoot a ray downwards through the boundingbox bottom corners, and if these are in the same plane than the face, raytest returns nil. Weird. -
ComponentInstance.glued_to()should return aSketchup::Faceobject if it's "on" a face,nilif not. -
@anton_s said:
Lets, say I write Two of my own simplified raytest functions (similar to
Raytest 2). One on C++ (raytest2cpp), compile it to .dll, and extern it into some of my Ruby module using dl. The other, on Ruby (raytest2rb). On SU, which of these will work faster, why, and approximately by how much percent faster?In order to do your own raytesting C++ function you'd have to pass the function all the 3D geometry in the model, and I assume that will eat up any performance gain you'd get from the actual custom raytracing.
Advertisement