threedle / GeoCode

GeoCode maps 3D shapes to a human-interpretable parameter space, allowing to intuitively edit the recovered 3D shapes from a point cloud or sketch input.
374 stars 25 forks source link

Are camera angles used by the model? #17

Open SanBingYouYong opened 7 months ago

SanBingYouYong commented 7 months ago

Hi,

I wonder if the angle information is used in the process, either passed to the network directly or in some other ways.

I notice there's performance loss when the model gets sketches of unseen angles, and I see that the custom DatasetSketch class returns the camera angle of current sketch file, but the wrapper around it are from standard library (DataLoader and lightning trainer). Not sure if this angle information is maintained along the way or dropped after checking that there are enough files of correct angles as specified by the recipe.yml file.

Thanks!

ofekp commented 7 months ago

Hello and thank you for your interest,

I am not sure I fully understood the question, I will describe what I think you need to know. However, please direct me to any spot you want to better understand. I would also like to understand if the performance degradation you speak of is in accuracy (in which case it is expected) or a computational one (i.e. something takes longer).

As you mentioned, the view angles are specified in the recipe files https://github.com/threedle/GeoCode/blob/main/dataset_generator/recipe_files/recipe_chair.yml#L311-L318 they are split between angles that we will train on and angles that will only be used for testing. During the dataset generation, we generate the sketches for all the angles. For training, we only use the sketches from the angles that are meant to be trained on, and we do not train on test-only sketch angles. https://github.com/threedle/GeoCode/blob/main/geocode/geocode_train.py#L30 During testing, we provide the dataset class with all the angles https://github.com/threedle/GeoCode/blob/main/geocode/geocode_test.py#L91

I hope this helps, let me know if you have any further questions.

SanBingYouYong commented 7 months ago

Thanks for the response!

The performance issue, also as it was mentioned in the supplementary materials, refers to accuracy drops, as in the shape it reproduces match less to the original sketch.

Also regarding this issue, I'll assume it's hard for human users to draw by hands a sketch of a given angle, thus the reproduced shape will often not be ideal? In my own experiments, I don't see a significant difference between angles seen and those unseen in training tho.

Also I keep getting results that oscillate between two shapes on one sketch, and it happens in many settings (angles, sketches, etc.). scrshot I modified the code (mainly the test process) to work on a single-image dataset where I put in my test sketches, and I wrote a Blender plugin to capture the annotation to sketches and run the inference, then it auto-fills the shape parameters. I wonder if this oscillation in results are due to minor differences on how I set up my scene or something else.

SanBingYouYong commented 7 months ago

This is basically how I set up my scene. I had to tweak things a bit to make the produced image similar to your dataset images, so the angle (especially the elevation -30degree down) might not be exactly the same. setup

SanBingYouYong commented 7 months ago

Here's one of my test images if you are interested in carrying out experiment on it too: -30degrees down and 15 degrees horizontally. It's generated using Freestyle engine in Blender with only simple postproc, so it might be a bit more noisy. single_img_-30 0_15 0

ofekp commented 7 months ago

Yes, the oscillation you are seeing is the direct result of the Random Horizontal Flip that is not disabled during the test phase: https://github.com/threedle/GeoCode/blob/main/data/dataset_sketch.py#L37C1-L37C47 A simple if statement or removing that line will solve that issue for you.

The user will not be able to draw with the same angle exactly. Ideally, 10 or even more views should be used during training. That will make things much more resilient to unseen angles. Interestingly, using a different encoder instead of VGG did not improve this result. This further supports the need for augmentation of the camera angles during the training phase.

SanBingYouYong commented 7 months ago

Thanks for the explanation.

I noticed a small issue of shape not updating properly after loading params to geometry nodes, specificially in other two domains (vase and table), and it turns out the original method (toggling obj.show_bounds) might not be sufficient, and the issue can be fixed by adding one more line of obj.data.update() after calling load_shape_from_yml. Strangely enough, replacing the original update method in https://github.com/threedle/GeoCode/blob/01afd9f6d3b05b77fd4a98eb7f323e13bd829316/common/bpy_util.py#L134-L135 to the latter did not solve the problem, and one would still have to call it one more time after loading params.

reference: https://blender.stackexchange.com/questions/163300/how-to-update-an-object-after-changing-its-uv-coordinates

ofekp commented 6 months ago

That is correct, the viewport should be updated using bpy.context.view_layer.update()

Is this what you did - https://github.com/threedle/GeoCode/pull/19? Let me know and I will merge.

Thank you very much 🙏

SanBingYouYong commented 6 months ago

Very strange that replacing the existing method with obj.data.update() did not work, but adding one extra line of that works, in the end of the whole parameter loading process. I'll try bpy.context.view_layer.update() later.

SanBingYouYong commented 6 months ago

Update: Replacing the original code with either method did not work for me. This might actually have something to do with my extracted pipeline. Fixing the issue with adding one more line in the end, the obj.data.update() method worked but bpy.context.view_layer.update() did not.

ofekp commented 6 months ago

Thank you for this @SanBingYouYong, I merged the fix with obj.data.update().

SanBingYouYong commented 3 months ago

Hi, now I'm trying to run a few epochs of training to see what a similar system should behave during training, but 30+ epochs passed the loss is not decreasing from 22+-1. Is it normal? Usually how many epochs would it take until we observe improvement?

SanBingYouYong commented 3 months ago

600 epochs passed and the loss decreased by 2, from 22 to 19. Is this expected or am I doing something wrong?

cg-py commented 3 months ago

The loss is exponentially decreasing, you should see a substantial decrease even after 1 epoch. Are you running only with sketch input? what is your training command? have you verified your dataset?

SanBingYouYong commented 3 months ago

command Dataset download link was removed, I used the dataset downloaded months ago when I was trying to do the integration. I'll manually inspect it and see what could go wrong once I get back to it.

cg-py commented 2 months ago

@SanBingYouYong sorry for removing the link, we will restore it eventually but there is no option to do it now. I may consider generating the data yourself as a workaround. Let me know if you need help with that.