Open3D
Open3D copied to clipboard
isl-org
Documentation for registration_fgr_based_on_feature_matching not updated
Checklist
- [X] I have searched for similar issues.
- [X] For Python issues, I have tested with the latest development wheel.
- [X] I have checked the release documentation and the latest documentation (for
mainbranch).
Describe the issue
the registration for registration_fgr_based_on_feature_matching was not updated after the rename of the function from registration_fast_based_on_feature_matching
Steps to reproduce the bug
read documentation at https://www.open3d.org/html/python_api/open3d.registration.registration_fast_based_on_feature_matching.html#open3d.registration.registration_fast_based_on_feature_matching
Error message
No response
Expected behavior
No response
Open3D, Python and System information
- Operating system: Ubuntu 20.04
- Python version: Python 3.8
- Open3D version: 0.18.0
- System architecture: x86
- Is this a remote workstation?: yes
- How did you install Open3D?: pip
Additional information
No response
Yes I would like this because I find the two diametrically opposed diffuse lights less than ideal. When I looked into it I got the impression the arrangement of the lights is a special hack for OpenCSG, so might not be easy or even possible to change.
A separate photo realistic render mode with smooth shading and proper lighting would be nice even if it was slow.
Oh, if OpenCSG depends on special lighting, that would be unfortunate. I guess we have to test that. I was hoping it's just a matter of adding the parameters. Even the anicent OpenGL code supports up to 8 light sources it seems.
For really good readering, I'd prefer we find a way to export enough information to some actual render software. It would be interesting to see what a good workflow could be there - the currently available options are a bit crazy hacks (e.g. convert STL to povray and such).
If the onging work on the OpenGL part works out, we may be able to add some nicer GPU-Shaders for better looking images but that probably won't benefit the preview mode.
Actually I think it can be improved as the current situation is described as a kudge:
A third workaround for the lighting problem is to place two identical light sources on the opposite sides of the CSG model: one of them illuminates polygons of intersected and the other one polygons of subtracted primitives facing to the same direction. While this may be a kludge, in practice this approach works well if we can accept an illumination that is equal from both sides of the CSG model.
http://www.opencsg.org/data/csg_freenix2005_paper.pdf
Hmm, just thinking out loud with 94.7% ignorance of CSG details... shouldn't it be possible to then retain the information it's drawing a difference and actually drawing the face flipped so the original lighting is used?
The other two options the document mentions are:
7.3 Lighting CSG Shapes For illuminating CSG shapes, it is important to distinguish between intersected and subtracted primitives: polygons of intersected primitives are oriented normally, but subtracted primitives have an inverse orientation because only their inner back-facing polygons can be visible. Therefore the lighting of subtracted primitives is, without precautions, inverse to the standard lighting: polygons that point away from the light are lighted, but polygons that are oriented towards the light source are unlighted.
The first option to fix this issue is to negate the normals of all subtracted primitives. This is likely the best option if vertex programs are used for geometrical transformations because a vertex program can implement the negation of normals easily. Otherwise this is a potentially more complicated operation, since the normals of primitives must be created analytically, respecting the CSG operation of the primitive. Negating normals is the only option that works correctly for shading by the means of per-pixel lighting respectively bumpmapping in a fragment program.
The second option for the standard vertex lighting is to enable two-sided lighting. In this case, vertices of back-facing polygons have their normals reversed before the lighting equation is evaluated. Unfortunately, some graphics hardware such as the GeForceFX takes a big performance hit with two-sided lighting. Apart from this performance weakness, this is a simple solution for correct lighting.
I would like what might be called flat, all-around or ambient lighting such that the orientation and view angle do not affect how the face colors appear.
My use case is an optical illusion which is ruined by shadows so that without this option I have to compensate for the shadows by changing the face colors. An option like I'm requesting would obviate that tedious effort.
all-around or ambient lighting such that the orientation and view angle do not affect how the face colors appear.
@rickan54 my needs are exactly the same as yours.
until then my workflow contains a post-processing phase where I reduce the number of colours in the image using greyscale and threshold processes. this may help you as a workaround as lighting in OpenSCAD is on an unknown timeline.
this tweet shows screenshots of my process: https://twitter.com/gingerbeardman/status/1292053112623169537
This is my illusion:
It's a view of 12 of the 30 faces of a rhombic triacontahedron. (It's arranged to be the OpenSCAD top view.)
If the lighting weren't so extraterrestrial, I would not have had to make it so dark, but it didn't turn out to be all that difficult to calculate the colors needed to produce this, and, now that I've made it, I see that it works better breaking the illusion by rotating the view with lighting that's not flat:
The limiting face is the one on the right side of the center three in the first view, and it's pure white. All the others are darkened to create the effect, i.e. all the other faces have to be less white (darker) to make it work.
(The bottom view looks the same and the six "equatorial" (not visible in top and bottom views) faces are white.)
Both images are unretouched screen copies of the OpenSCAD view.
I, too, would appreciate a way to set the position of the light point(s) say, $vpl = [x,y,z]; or if multiple points are needed $vpl =[[x,y,z], ... , [xn, yn, zn]];. Would$vpl be view-point-relative lighting? -- for a helmet-lamp light effect. Or is it scene-lighting? -- which might be useful for product illustrations. $vpl = [[[x,y,z], ..., scene_xyz_n], [headlamp, flashlight]];??
My current use-case is scanning etched barcodes from the screen during testing. In the concrete case of view-from-above, I find I have to tip the model forward to increase the brightness and contrast of the barcodes, but in preview mode this leads to jaggies that I would like to avoid.
I had a moment of clarity and realised that I could render the model twice, first as normal and second with the main colours switched. In this second image white elements are now black, so they cannot become any darker in the lighting shadows. 😎
Post-processing: I negate the second image back to normal colours, to make the highlights white again, and finally composite both images into a single image.
Works a treat!
I had a simple feature request on the OpenSCAD general discussion Mailing-list and it was suggested by Torsten Paul that I make a comment here, so I'm doing just that.
I can explain the feature request in three parts: (1) What sort of special functionality can be conditionally activated, (2) How one might activate this special functionality, and (3) How to implement the feature.
(1) Now obviously 3D solids are drawn by OpenSCAD in the 3D window with some sort of fixed lighting, which works great in most cases. There arose a specific need. OpenSCAD is great at making 2D graphs and 2D cutaway schematics. Sample videos of this can be seen here: https://odysee.com/@Neri_Engineering/gimbal-cv-ver1-360-orange-green-calc-40-incident https://odysee.com/@Neri_Engineering/profiles However the objects in these 2D drawings ("ortho" projection) are still being shaded, depending on the surface angle with light sources. Ideally, in these sorts of cases, the lighting would be full-blast 100% ambient, and what I mean by this is that regardless of the normal vector direction of surface, it would be 100% of its assigned color all the time. This way a curved line that is part of a graph, which is made of small spheres, would be a solid color along the width of the line. The cutaway surfaces that are to be rendered in a 2D schematic would also be more predictable in their color, and could be easily assigned to their exact colors, regardless of angle and lighting arrangement. Please note, in a 3D view, this sort of lighting model would make absolutely no sense, because objects of one color would look like blobs. Only the silhouette would be visible, in contrast to a background. Also please note, in these types of instances it's likely that the image capture is being done from command-line and command-line only. Therefore if this feature is only accessible from the command-line, it would be totally okay.
(2) How would you activate this strange feature, of casting 100% ambient light on all surfaces? I would suggest activating it via environment variable. E.g., something like OPENSCAD_NO_SHADING=y. Something like this. Or OPENSCAD_FULL_AMBIENT_LIGHTING=true.
(3) How would you implement this feature? There would be two steps. First, a cross-platform test for an environment variable being set. Perhaps it would be enough to only test that the particular environment variable is set to some non-empty string. The test would have to work on all systems, Linux, FreeBSD, Window, Mac, etc., of course. Next, if the environment variable is set as specified, then do special fork in the lighting code. And this is where I began to experiment but soon realized that I need to become much more familiar with OpenGL before I can make a meaningful change. To experiment, I downloaded OpenCSG 1.4.2 and had a look at main/example.cpp. In the init() function there, I began to experiment with lines of code that look like this:
// Enable two OpenGL lights
GLfloat light_diffuse[] = { 1.0f, 0.0f, 0.0f, 1.0f}; // Red diffuse light
GLfloat light_position0[] = {-1.0f, -1.0f, -1.0f, 0.0f}; // Infinite light location
GLfloat light_position1[] = { 1.0f, 1.0f, 1.0f, 0.0f}; // Infinite light location
glLightfv(GL_LIGHT0, GL_DIFFUSE, light_diffuse);
glLightfv(GL_LIGHT0, GL_POSITION, light_position0);
glEnable(GL_LIGHT0);
glLightfv(GL_LIGHT1, GL_DIFFUSE, light_diffuse);
glLightfv(GL_LIGHT1, GL_POSITION, light_position1);
glEnable(GL_LIGHT1);
I was able to produce an effect by e.g. removing one of the lights but I was not able to figure out how to flood the scene with a strong 100% ambient light, nor did I try to remove shading/lighting altogether. I didn't have enough time to do enough research to make meaningful progress, and other duties called upon me. But I assume that there would be a similar section of code in OpenSCAD, and it would be a matter of finding it, and then figuring out the most robust way, in OpenGL, to remove shading/lighting in favor of a full color effect with no lighting that is. I have a feeling that it's very simple and that I'm just missing something very obvious. And yes I'm not an expert in OpenGL.
Please don't make it an environment variable. Please don't make anything new be an environment variable. Environment variables are a totally alien way to do things in Windows. There is no convenient way to set them for a single program, and the UI to set them for the user is well-hidden and few users are aware of it.
I'd say that the lights should be controlled by $ variables, just as the camera position is. They could also be controlled by dynamic (that is, not-saved) UI choices and CLI options, again as the camera position is. (But note: the light sources look like they are positioned relative to the camera, not to the model. As you move the model around, its lighting changes.)
The relevant function seems to be GLView::initializeGL(), in src/glview/GLView.cc.
Changing GL_DIFFUSE to GL_AMBIENT appears to do what you want.
diff --git a/src/glview/GLView.cc b/src/glview/GLView.cc
index 12e4042b0..f2925ea9f 100644
--- a/src/glview/GLView.cc
+++ b/src/glview/GLView.cc
@@ -276,10 +276,10 @@ void GLView::initializeGL()
glMatrixMode(GL_MODELVIEW);
glLoadIdentity();
- glLightfv(GL_LIGHT0, GL_DIFFUSE, light_diffuse);
+ glLightfv(GL_LIGHT0, GL_AMBIENT, light_diffuse);
glLightfv(GL_LIGHT0, GL_POSITION, light_position0);
glEnable(GL_LIGHT0);
- glLightfv(GL_LIGHT1, GL_DIFFUSE, light_diffuse);
+ glLightfv(GL_LIGHT1, GL_AMBIENT, light_diffuse);
glLightfv(GL_LIGHT1, GL_POSITION, light_position1);
glEnable(GL_LIGHT1);
glEnable(GL_LIGHTING);
Here's a cube:
You can also do that in shaders very easily. This doesn't even require rebuilding OpenSCAD, since shaders are compiled during runtime.
Edit shaders/Preview.frag, and replace the main function with
void main(void) {
gl_FragColor = color1;
}
Then run openscad again and enable and Preview with Show Edges enabled (Currently the Preview shader is only used for preview with edges visible, but this shader change makes it ignore edges).
I'm not sure more of the $ variables are a good idea. They were a short-cut for $vpX as those already existed for reading and this has proven it's a quite bad interface for controling display options. So far the main use cases seem to be for batch export anyway, so the first candidate for this configuration might be the command line.
Command-line option would be great. Perhaps better than environment variable.
Jordan, in the image you attached, the right face of the cube is at RGB = (255,255,117) while the top and front sides of the cube are at RGB = (255,255,97). I too had problems with getting the color to be the same on all sides, and soon realized that I'd leave it to the experts.
@neri-engineering I am not even a beginner at OpenGL stuff. I just took some obvious-looking keywords and plugged them in. Perhaps it has to do with having two lights? I could probably turn off one of them and regenerate that image. But it sounds like @thehans may have a better answer.
@t-paul WRT using $ variables to control the camera and the lights... it's definitely useful to be able to control the camera from inside the program, to support an animation that moves the camera. I don't know whether programmatically moving the lights would be sensible, but it seems likely. (Start with the fact that the lights seem to stay "near" the camera; if you wanted to have the lighting fixed as you moved the camera around, you'd have to move the lights to compensate.) What problems are you thinking of? One obvious problem (or maybe pitfall) is scoping: you can only have one camera location for the model, but there can be many different instances of any particular $variable. But I agree that it could be done first as a CLI option and/or GUI option, akin to the CLI/GUI camera controls.
I'd like this also. It's frustrating I can't get the model in the orientation I want to take a snapshot while still having the face decently lit.
One idea that I've been playing with (not to the level of implementing) would be to have lights as model elements.
That is, you'd have a light(<params>) module that would drop a light at the origin, pointing (say) toward +Z. The parameters would control the shape of the light (point, plane, angles). You could apply whatever transforms you like to position that light.
You could add as many lights as you like.
Not this topic, but I've had similar thoughts about cameras. Position cameras as you like, and a menu would let you pick which camera to look through. Better, allow multiple windows looking through different cameras at the same time.
@jordanbrown0 this was what I expected I would be able to do (lights) and was shocked to find I could not.
... and as follow-up provide all the light and camera positions as a nice data structure to the export modules, so that exports that can make use of it if that helps their presentation (such as the Povray export in #5288).
OpenSCAD's primary goal is to yield a 3D model, not to yield images. Yielding images is just part of the user interface for building the model. Not that it can't be used for other purposes, but (e.g.) designing even-sort-of-realistic scenes isn't one of the goals.
Perhaps it can and should evolve that way, but so far it's been a non-goal.
I don't personally want realistic images, i just want to control the position of the light source.
Note that with either the $-variable or light() schemes it would not be possible to duplicate the current behavior, where the light's position is tied to the camera's position. Today, when you move the camera around the lights move with it, without rerunning the OpenSCAD program. (Or if you look at it the other way, when you move the model around the camera and lights don't move.)
My goal is to have a model that is not lit at all, or uniformly lit so there are no shadows cast at all, or shadows that I can control.