3d driving#382
Conversation
Made comments to file
Started writing code to parse elevationProfile and lateralProfile elements.
This reverts commit 72a31f2.
Trying to take 3 dimensional vectors and display them, currently displays visual window, but doesn't show anything
Doesn't quite work yet, but I have differentiated functions such as calc_geometry_for_type() to calculate different things for 2D and 3D
Doesn't work yet, currently facing an error where PolylineRegion and PathRegion are not compatible.
Made sure that all PathRegions created are created through points
Updated the FollowLaneBehavior function to deal with 2d and 3d points
…efore Region initialization
…(CarlaActor.setPosition and SetTransformAction)
…ving model centerOnSurface to derive surface orientation from element at contact point
Handle MeshSurfaceRegion/MeshVolumeRegion intersections through a custom sampler instead of the generic intersection fallback. The sampler filters surface triangles using bounding-box overlap with the volume, then samples from the reduced surface and checks points against the volume exactly. This improves 3D sampling enough to go back to using the same basic.scenic CARLA test scenario instead of needing a separate 3D-specific case. Also add core region tests covering sampler wiring and sampling behavior for surface-volume intersections.
Update test_car_clipping_3D to generate a scene instead of only compiling, and allow either InvalidScenarioError or RejectionException. With dynamic CARLA blueprints, default car dimensions depend on the sampled blueprint, so overlapping cars will not be rejected during the early static validation pass and instead will fail during scene generation.
|
The test suite was passing except for the two CARLA tests in The new surface-volume sampler, |
| numpy.linalg.norm(b - a, axis=1), (len(a), 1) | ||
| ) | ||
|
|
||
| def intersects(self, other, triedReversed=False): |
There was a problem hiding this comment.
The implementation here is not correct: it ignores the Z coordinates. Using Shapely isn't a bad idea (it's probably faster than trying to compute intersections ourselves), but you'd have to check that at least one of the 2D intersections it finds is actually an intersection in 3D. For intersection points, that's easy; for segments, I think it's enough to check each of the endpoints.
| regionContainedIn: roadOrShoulder | ||
| position: new Point on road | ||
| regionContainedIn: roadOrShoulder.boundingPolygon # Change region to bounding polygon region | ||
| position: centerOnSurface(road, self.baseOffset, self.contactTolerance) |
There was a problem hiding this comment.
I think I see why we need this now, but with a mechanism for default specifiers, this would be equivalent to simply on road, I think.
| startDir = None | ||
| endDir = None | ||
| if isinstance(connecting.centerline, PathRegion): | ||
| startDir = ( | ||
| connecting.centerline.vertices[0] - connecting.centerline.vertices[1] | ||
| ) | ||
| endDir = ( | ||
| connecting.centerline.vertices[-2] - connecting.centerline.vertices[-1] | ||
| ) | ||
| else: | ||
| startDir = connecting.centerline[1] - connecting.centerline[0] | ||
| endDir = connecting.centerline[-1] - connecting.centerline[-2] |
There was a problem hiding this comment.
I think we can revert this change since PathRegion.__getitem__ was added above. (Also the indices look backwards for the PathRegion case -- better double-check this!)
| polygon=self.polygon, orientation=self.orientation, name=self.name | ||
| ) | ||
| if isinstance(self.region, MeshSurfaceRegion): | ||
| self.region.__init__( |
There was a problem hiding this comment.
Shouldn't call __init__ again: the region is already initialized.
3 participants
Description
This PR adds support for 3D mode.
Issue Link
N/A
Checklist
pytestand/or other meansAdditional Notes
N/A