Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support for more 2D and 3D primitives #1361

Open
jleibs opened this issue Feb 20, 2023 · 16 comments
Open

Support for more 2D and 3D primitives #1361

jleibs opened this issue Feb 20, 2023 · 16 comments
Assignees
Labels
enhancement New feature or request 🔺 re_renderer affects re_renderer itself user-request This is a pressing issue for one of our users
Milestone

Comments

@jleibs
Copy link
Member

jleibs commented Feb 20, 2023

It would be nice to be able to log the common 2D/3D geometry building blocks in order to enable building up simple 3D models without going all the way to fully specified meshes.

Some basics:

  • Rect / Box
  • Circle / Sphere
  • 2D Ellipse and 3D Ellipsoid (for e.g. covariance estimation)
  • Triangle / Cone
  • Cylinder
  • Capsule
  • Ray3D
  • Plane

Maybe more, but good enough for VRML, good enough for me?

These should all consistently support components for OutOfTreeTransform3D, Color, and Fill.

@jleibs jleibs added enhancement New feature or request 🔺 re_renderer affects re_renderer itself labels Feb 20, 2023
@emilk
Copy link
Member

emilk commented Apr 27, 2023

I think we should add a minimal version of this ASAP - it can be something that just generates meshes during scene construction for now. This is very limiting at the moment, and we need this to test other things like transparency, 2D layering, and styling.

@emilk
Copy link
Member

emilk commented May 1, 2023

An interesting note: a Rectangle component is useful both in 2D and 3D.

For 2D we support it via specifying its min/max corners, or center and size, and some other options. We will also add support for 2D transforms (#349).

For 3D we may want the same 2D interface plus a 3D transform, treating the 2D rect as a 3D shape with an implicit Z=0.

@emilk emilk changed the title Support for more 3D primitives Support for more 2D and 3D primitives May 2, 2023
@emilk
Copy link
Member

emilk commented May 3, 2023

Rect/Box we have, but needs styling (Separate issue).

Cylinders and capsules I think are very useful (e.g. limbs)

2D circles/discs are very useful. So are spheres. What is the difference with point?

Point radii can be auto and ui-based, but spheres/circles need a real radius.
A sphere/circle would squash with non-uniform transforms.
Points are using a faster, less accurate, renderer.

@abey79 abey79 added the user-request This is a pressing issue for one of our users label Oct 27, 2023
@abey79 abey79 added this to the Triage milestone Oct 27, 2023
@jeongseok-meta
Copy link

It would be great to have a way to visualize the grid or ground. This could be achieved through a loggable object or simply as a visual artifact.

@Wumpf
Copy link
Member

Wumpf commented Jan 18, 2024

@jeongseok-meta yeah I think this should be builtin feature of the viewer that doesn't require logging anything (other than maybe logging the settings itself on the space view once code configurable views are there). There's already a separate issue for this:

@mont1004
Copy link

mont1004 commented Apr 8, 2024

Hi there.

Just curious, has there been any progress or updates on this topic? Would love to know what's going on.
I personally hope for support of an ellipsoid representation in physical units, which can be beneficial for expressing the ambiguity in, for example, camera pose estimation.

@abey79
Copy link
Member

abey79 commented Apr 8, 2024

@mont1004 Unfortunately the next release will have little new on this front, but this is still something that's high on our priority list. Do you have any particular primitive in mind that you would need most?

@mont1004
Copy link

mont1004 commented Apr 8, 2024

@abey79 Thank you for the quick reply!

My team has been developing Visual SLAM, and we've been eyeing the rerun as a top candidate for our new visualizer. As I mentioned earlier, we currently represent the covariance of the estimated camera poses with ellipsoids. Having ellipsoids that can be scaled and compared in size with one another would be very helpful, as this capability is crucial for us.

@pablovela5620
Copy link
Contributor

Want to add like #6012 that adding text to an image, similar to OpenCV would be appreciated, oftentimes I don't want to log something in textlog/textdocument as I would like it to show in the image itself. As a work around I log a point2d or linestrip with 0 radius and add a label. This works, but I can't easily change the size of the font like cv2.drawtext would allow

@nikolausWest
Copy link
Member

@pablovela5620: Are you adding the text to a particular place in the image (i.e. tying it to a geometric location), or is the text more of a description of the image (i.e. it could alternatively be below the image for instance)?

@pablovela5620
Copy link
Contributor

Generally to a geometric location, for example detecting someone's face and placing the text next to or above their detected face. Then telling them to either get closer or farther from the screen or to move their face to a specific location. Below an image could also be helpful (though I think this would already be possible with a textdoc + blueprint?)

@nikolausWest
Copy link
Member

nikolausWest commented Jun 10, 2024

Rays and planes as per #2179 would be great

@emilk
Copy link
Member

emilk commented Jun 10, 2024

For the 3D primitives, we should have a style option to either render them as solid, as wireframe, or both. The spatial space-view can convert them to a re_renderer mesh and/or lines as needed. Initially we could keep the coarseness of these primitives hard-coded (i.e. how many subdivisions of a sphere).

To keep things simple, I suggest we use the Transform3D OutOfTreeTransform3D archetype to orient and position the shapes. This means that e.g. a cylinder would always have its base at the origin, and be defined by Cylinder { radius, height }.

Which axis should "height" be along? I doesn't really matter, but once we picked something we should stick with it forever, and also use it for all other shapes (i.e. the axis along which a capsule and cylinder stretches). It's worth spending some time investigating what is the most common choice in other visualization tools. (VRML uses Y as primary axis)

We should still have nice helpers to construct these primitives. For instance, defining a capsule by two points and a radius (a fat line segment) but then logging that as a single component Capsule { radius, length } plus an Transform3D OutOfTreeTransform3D. This would mean an archetype Capsule would also contain archetype.Transform3D in a sense, which may require some more codegen design/thinking.

For the 3D ellipsoids: I did some preliminary experimentation with these in #4991

@teh-cmc
Copy link
Member

teh-cmc commented Jun 10, 2024

We should still have nice helpers to construct these primitives. For instance, defining a capsule by two points and a radius (a fat line segment) but then logging that as a single component Capsule { radius, length } plus an Transform3D. This would mean an archetype Capsule would also contain archetype.Transform3D in a sense, which may require some more codegen design/thinking.

We use the OutOfTreeTransform3D component for this today; it has worked well for Asset3D.

(PS: don't mind my edit on your comment, I inadvertently pressed Edit instead of Quote -.-)

@emilk
Copy link
Member

emilk commented Jul 1, 2024

A less important, but very nice, primitive, is the tapered capsule:

image

@kpreid kpreid self-assigned this Jul 1, 2024
emilk added a commit that referenced this issue Jul 15, 2024
### What

Implement an `Ellipsoids` archetype and visualizer. This may be used to
render ellipsoids, or spheres where `Points3D` is unsuitable because the
actual boundary in space is significant. It is intended as a first step
towards completing #1361, by adding ellipsoids and by sketching out a
general mechanism for rendering procedurally-generated shapes, which
will be reusable for cylinders and anything which needs many vertices to
render.

The archetype, extensions, etc. are largely forked off of `Boxes3d`.

Unfinished parts / future work:

* Currently, the spheres are always drawn as wireframes (with an
automatically chosen mesh subdivision level). We will want to also
support solid rendering (i.e. triangles in place of lines), but many use
cases for spheres might want them to be transparent, which isn't yet
properly supported in 3D space views (#702), so I chose wireframe as the
first version.

* Currently, all of the wireframe lines are piped through the
`LineDrawableBuilder` every frame. Instead, they should be drawn as
instanced meshes; that will require implementing a new renderer that
invokes the existing line shader with the different data layout.
However, this current implementation should not be worse than if the
user were to create a similar number of lines directly.

* The sphere mesh needs a choice of subdivision level. Currently, it is
automatically derived from the size of the sphere in the scene, which
may be inappropriate depending on the scale of scene units or the
specific application. I'd like feedback on the best way to handle this.
Just add another component, perhaps kind of like the `Radius` component?

* I‘m not sure what the best way to handle the (future) errors in
generating meshes is. Should it return a `SpaceViewSystemExecutionError`
(which hides unrelated data), just draw nothing and continue (which
could lead to silent missing data), or something else?


![rerun_example_ellipsoid_batch](https://github.com/rerun-io/rerun/assets/779501/5ad90a6e-720d-44b0-883d-e3213777345e)


### Checklist
* [X] I have read and agree to [Contributor
Guide](https://github.com/rerun-io/rerun/blob/main/CONTRIBUTING.md) and
the [Code of
Conduct](https://github.com/rerun-io/rerun/blob/main/CODE_OF_CONDUCT.md)
* [x] I've included a screenshot or gif (if applicable)
* [ ] I have tested the web demo (if applicable):
* Using examples from latest `main` build:
[rerun.io/viewer](https://rerun.io/viewer/pr/6853?manifest_url=https://app.rerun.io/version/main/examples_manifest.json)
* Using full set of examples from `nightly` build:
[rerun.io/viewer](https://rerun.io/viewer/pr/6853?manifest_url=https://app.rerun.io/version/nightly/examples_manifest.json)
* [X] The PR title and labels are set such as to maximize their
usefulness for the next release's CHANGELOG
* [x] If applicable, add a new check to the [release
checklist](https://github.com/rerun-io/rerun/blob/main/tests/python/release_checklist)!
* [x] If have noted any breaking changes to the log API in
`CHANGELOG.md` and the migration guide

- [PR Build Summary](https://build.rerun.io/pr/6853)
- [Recent benchmark results](https://build.rerun.io/graphs/crates.html)
- [Wasm size tracking](https://build.rerun.io/graphs/sizes.html)

To run all checks from `main`, comment on the PR with `@rerun-bot
full-check`.

---------

Co-authored-by: Emil Ernerfeldt <[email protected]>
Wumpf added a commit that referenced this issue Jul 24, 2024
…`Ellipsoids`. (#6953)

### What

With these changes, `Boxes3D` and `Ellipsoids` can now be viewed as
solid objects. This is part of the work on #1361 and the mechanisms
added here will generalize to other shapes.

* Add new component type `SolidColor`. This is identical to `Color`
except that, on shapes where it applies, it sets the color of surfaces
instead of lines. Whether its color is transparent controls whether the
surfaces are drawn at all.
* Add `SolidColor` to the `Boxes3D` and `Ellipsoids` archetypes.
* Add support for solid colors to those archetypes’ visualizers.
* Add `proc_mesh::SolidCache` to cache the calculation of triangle
meshes.
* Add `proc_mesh::ProcMeshKey::Cube` to allow the cached mech mechanism
to generate solid cubes.

![Screenshot 2024-07-20 at 17 36
01](https://github.com/user-attachments/assets/ab6b2d1b-20d0-471c-ba49-25d4e10638ea)
![Screenshot 2024-07-20 at 17 35
12](https://github.com/user-attachments/assets/2d6ce740-5bd5-4475-a018-4d286adf2c5b)

Future work (things this PR *doesn't* do):

* Viewer UI needs a version of the color picker that lets you pick
"fully transparent".
* The line renderer does not play well with adjacent faces, causing line
width to be halved some of the time. This could be fixed with something
like #6508, simple depth offsets, or something else.
* Getting naming and semantics right:
* Should the `colors` of `Boxes3D` be renamed `line_colors`, or
something like that? I think so, but that would be a breaking change, so
I didn't in this PR.
    * Should `Color` be renamed?
* Should there be all 3 of `SolidColor`, LineColor`, and `Color` with
some override policy between them?
    * Should `SolidColor` be called `SurfaceColor` instead?
    * How should `SolidColor` interact with annotation contexts?
* Figure out whether instanced meshes are the right choice for
performance.

### Checklist
* [X] I have read and agree to [Contributor
Guide](https://github.com/rerun-io/rerun/blob/main/CONTRIBUTING.md) and
the [Code of
Conduct](https://github.com/rerun-io/rerun/blob/main/CODE_OF_CONDUCT.md)
* [X] I've included a screenshot or gif (if applicable)
* [x] I have tested the web demo (if applicable):
* Using examples from latest `main` build:
[rerun.io/viewer](https://rerun.io/viewer/pr/6953?manifest_url=https://app.rerun.io/version/main/examples_manifest.json)
* Using full set of examples from `nightly` build:
[rerun.io/viewer](https://rerun.io/viewer/pr/6953?manifest_url=https://app.rerun.io/version/nightly/examples_manifest.json)
* [X] The PR title and labels are set such as to maximize their
usefulness for the next release's CHANGELOG
* [X] If applicable, add a new check to the [release
checklist](https://github.com/rerun-io/rerun/blob/main/tests/python/release_checklist)!
* [X] If have noted any breaking changes to the log API in
`CHANGELOG.md` and the migration guide
* The `Ellipsoids` archetype has a renamed field but that isn't released
yet, so doesn't need noting.

- [PR Build Summary](https://build.rerun.io/pr/6953)
- [Recent benchmark results](https://build.rerun.io/graphs/crates.html)
- [Wasm size tracking](https://build.rerun.io/graphs/sizes.html)

To run all checks from `main`, comment on the PR with `@rerun-bot
full-check`.

---------

Co-authored-by: Andreas Reich <[email protected]>
@kpreid
Copy link
Collaborator

kpreid commented Jul 24, 2024

Progress update:

More 3D shapes to come!

@Wumpf Wumpf mentioned this issue Aug 15, 2024
Wumpf pushed a commit that referenced this issue Sep 26, 2024
### What

`ProcMeshVisBuffer` extracts common elements from `Boxes3DVisualizer`
and `Ellipsoids3DVisualizer`. This will be useful to minimize duplicated
code when further proc-mesh shapes are added (#1361).

Additionally, `ComponentFallbackProvider` is no longer a supertrait of
`VisualizerSystem`. Instead, the fallback provider is always accessed
through `as_fallback_provider()` (which may return `&self` if it likes).
The advantage of this is that a visualizer may access its desired
fallback logic even while parts of itself are exclusively borrowed, by
putting the `TypedComponentFallbackProvider` implementations on a
separate type. (Strictly speaking, the supertrait change is not needed,
if we instead let a `ComponentFallbackProvider` implementation be made
from `TypedComponentFallbackProvider`s on a different type, but that
seems like a worse design to me.)

### Checklist
* [X] I have read and agree to [Contributor
Guide](https://github.com/rerun-io/rerun/blob/main/CONTRIBUTING.md) and
the [Code of
Conduct](https://github.com/rerun-io/rerun/blob/main/CODE_OF_CONDUCT.md)
* [X] I've included a screenshot or gif (if applicable)
* [ ] I have tested the web demo (if applicable):
* Using examples from latest `main` build:
[rerun.io/viewer](https://rerun.io/viewer/pr/7507?manifest_url=https://app.rerun.io/version/main/examples_manifest.json)
* Using full set of examples from `nightly` build:
[rerun.io/viewer](https://rerun.io/viewer/pr/7507?manifest_url=https://app.rerun.io/version/nightly/examples_manifest.json)
* [X] The PR title and labels are set such as to maximize their
usefulness for the next release's CHANGELOG
* [X] If applicable, add a new check to the [release
checklist](https://github.com/rerun-io/rerun/blob/main/tests/python/release_checklist)!
* [X] If have noted any breaking changes to the log API in
`CHANGELOG.md` and the migration guide

- [PR Build Summary](https://build.rerun.io/pr/7507)
- [Recent benchmark results](https://build.rerun.io/graphs/crates.html)
- [Wasm size tracking](https://build.rerun.io/graphs/sizes.html)

To run all checks from `main`, comment on the PR with `@rerun-bot
full-check`.
@kpreid kpreid mentioned this issue Oct 2, 2024
6 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request 🔺 re_renderer affects re_renderer itself user-request This is a pressing issue for one of our users
Projects
None yet
Development

No branches or pull requests

10 participants