Map Camera Coordinates to UV layer #19862

New Issue

Roland Hess · 2009-11-11T16:47:56+01:00

Roland Hess commented

2009-11-11 16:47:56 +01:00

%%%As we all know, moving the camera even a little can wreak havoc with sticky coordinates during camera mapping. The old solution is to make sticky coordinates, then "bake" them to traditional face-based uv's with a python script. Not a bad plan, and it sure beats fighting with the UV Project modifier.

Better still? This enhancement to the newly-reconnected add_sticky operator. A new operator is added that calls the same structure but uses a property to toggle for "map to uvs." This makes stickies and maps them to a new standard (face-based) UV coordinate layer.

With this in place, camera mapping becomes perfectly stable, letting you do whatever you want with the camera without worrying about your stickies going bananas.

Workflow: Select object and set texture mapping style to Window (or whatever you prefer). Use "Add Sticky as UV" operator. Set your mapping style to UV. Done. Well, you should line up your active camera first if you want good results.

I pulled the logic from scripts by Brandano and eeshlo.

NOTE TO REVIEWER: If you are inclined to include this patch, please send me an email ( m e @ h a r k y m a n dot c o m ) so I can do it. You big shots get all the committing fun!%%%

%%%As we all know, moving the camera even a little can wreak havoc with sticky coordinates during camera mapping. The old solution is to make sticky coordinates, then "bake" them to traditional face-based uv's with a python script. Not a bad plan, and it sure beats fighting with the UV Project modifier. Better still? This enhancement to the newly-reconnected add_sticky operator. A new operator is added that calls the same structure but uses a property to toggle for "map to uvs." This makes stickies and maps them to a new standard (face-based) UV coordinate layer. With this in place, camera mapping becomes perfectly stable, letting you do whatever you want with the camera without worrying about your stickies going bananas. Workflow: Select object and set texture mapping style to Window (or whatever you prefer). Use "Add Sticky as UV" operator. Set your mapping style to UV. Done. Well, you should line up your active camera first if you want good results. I pulled the logic from scripts by Brandano and eeshlo. NOTE TO REVIEWER: If you are inclined to include this patch, please send me an email ( m e @ h a r k y m a n dot c o m ) so I can do it. You big shots get all the committing fun!%%%

Roland Hess commented

2009-11-11 16:47:56 +01:00

Changed status to: 'Open'

Brecht Van Lommel commented

2009-11-11 17:31:40 +01:00

%%%This is useful functionality, but it shouldn't require creating sticky coordinates. This can be an option in the UV Unwrap menu.%%%

Roland Hess commented

2009-11-11 19:10:48 +01:00

%%%I'll see what I can do with it. Only problem with putting it with unwrap methods (which it obviously is) is that the mapping works through the renderer (sticky uses render methods), and only in object mode, while the rest of the uv methods only work from edit mode. I seem to remember Campbell (or someone) dealing with ops that needed to flip into/out of edit mode to work, so I'll look into that.%%%

yellow .... commented

2009-11-15 17:30:49 +01:00

%%%As one who has fought with the ProjectUV modifier and read a lot of tutorials on Camera Projection Dylon Cole, Chris Stoski, then tried to translate the very common process to blender and on the whole failed, it would be great to see the UVProject modifier improved so it is no longer a fight. :-)

There are a lot of tutorials for all 3D apps out there on Camera Mapping translatable to blender if only the UVProject worked nicely, there are not so many tutorials on blenders obscure answer to Camera Mapping 'stickys'.

Perhaps other 3D apps have sticky coordinates.

Sorry if this comment is not suitable here on the patch tracker.%%%

%%%As one who has fought with the ProjectUV modifier and read a lot of tutorials on Camera Projection Dylon Cole, Chris Stoski, then tried to translate the very common process to blender and on the whole failed, it would be great to see the UVProject modifier improved so it is no longer a fight. :-) There are a lot of tutorials for all 3D apps out there on Camera Mapping translatable to blender if only the UVProject worked nicely, there are not so many tutorials on blenders obscure answer to Camera Mapping 'stickys'. Perhaps other 3D apps have sticky coordinates. Sorry if this comment is not suitable here on the patch tracker.%%%

Roland Hess commented

2009-11-18 20:46:40 +01:00

%%%Complete rework. Abandoned stickies and the accompanying code that pumped things through the renderer to achieve coordinates.

This new patch adds a new op to uv unwrapping: Project from Camera. I've tested it throughout the entire range of camera lens values, negatively scaled meshes, camera inside mesh -- basically all the weird stuff I could think of and it seems to be solid. If there is no active camera, or if some other object is the camera (which can happen), or if it's an ortho camera, the process gently degrades to using the regular Project from View algo.

This should make everyone happy!%%%

%%%Complete rework. Abandoned stickies and the accompanying code that pumped things through the renderer to achieve coordinates. This new patch adds a new op to uv unwrapping: Project from Camera. I've tested it throughout the entire range of camera lens values, negatively scaled meshes, camera inside mesh -- basically all the weird stuff I could think of and it seems to be solid. If there is no active camera, or if some other object is the camera (which can happen), or if it's an ortho camera, the process gently degrades to using the regular Project from View algo. This should make everyone happy!%%%

Daniel Salazar commented

2009-11-18 23:50:17 +01:00

%%%I don't get this, camera projection has never been a problem since we got UV Project modifier!%%%

Roland Hess commented

2009-11-19 01:30:38 +01:00

%%%Nothing's wrong with UV Project (although it won't live update in my latest compile o' 2.5). But the workflow is: make uv layer. Add material and texture. Add image in UV/Image editor. Set material to TextureFaces (unless that's not needed anymore). Add UV project modifier. Set camera object. Possibly choose image in modifier panel. Adjust positioning and mesh in 3D view, while in Textured mode. Apply modifier.

The other workflow is: Add material and texture. Enter camera view. Adjust mesh in wireframe to match background image. Project UVs from camera.

Believe me, I can see the advantages of the modifier method, but Projecting UVs from the Camera is a simpler process. It is not a bad thing to have different ways to achieve the same result. One of the great things about Photoshop (IMHO) is that when one of my colleagues asks me how to do something, I can usually think of five different ways to do it.%%%

%%%Nothing's wrong with UV Project (although it won't live update in my latest compile o' 2.5). But the workflow is: make uv layer. Add material and texture. Add image in UV/Image editor. Set material to TextureFaces (unless that's not needed anymore). Add UV project modifier. Set camera object. Possibly choose image in modifier panel. Adjust positioning and mesh in 3D view, while in Textured mode. Apply modifier. The other workflow is: Add material and texture. Enter camera view. Adjust mesh in wireframe to match background image. Project UVs from camera. Believe me, I can see the advantages of the modifier method, but Projecting UVs from the Camera is a simpler process. It is not a bad thing to have different ways to achieve the same result. One of the great things about Photoshop (IMHO) is that when one of my colleagues asks me how to do something, I can usually think of five different ways to do it.%%%

Brecht Van Lommel commented

2009-11-26 14:37:17 +01:00

%%%Review:

Patch doesn't apply cleanly for me, says it's malformed, did you edit it manually or so?
It's using spaces instead of tabs, even on lines you aren't editing? Blender C code convention is tabs.
There's also a space at the end of each line, but perhaps that is due to windows line endings.
The operator should not have a "camera" property. Either you make two separate operators and give them different exec functions (which can still call a common function), or you make one operator with a property, not both. I think two operators is preferable here.
The magic camera->angle*0.01745f value should be replaced by DEG2RAD(camera->angle).
The pv variable in uv_from_camera is not used for anything.
There's no need to copy RenderData, you can make a pointer to it, like RenderData *r = &scene->r or just use scene->r.xsch directly, but copying is strange.
This should really work for orthographic cameras too, right now it will project from view in that case.%%%

%%%Review: * Patch doesn't apply cleanly for me, says it's malformed, did you edit it manually or so? * It's using spaces instead of tabs, even on lines you aren't editing? Blender C code convention is tabs. * There's also a space at the end of each line, but perhaps that is due to windows line endings. * The operator should not have a "camera" property. Either you make two separate operators and give them different exec functions (which can still call a common function), or you make one operator with a property, not both. I think two operators is preferable here. * The magic camera->angle*0.01745f value should be replaced by DEG2RAD(camera->angle). * The pv variable in uv_from_camera is not used for anything. * There's no need to copy RenderData, you can make a pointer to it, like RenderData *r = &scene->r or just use scene->r.xsch directly, but copying is strange. * This should really work for orthographic cameras too, right now it will project from view in that case.%%%

Roland Hess commented

2009-11-27 03:51:48 +01:00

%%%Okay. Addressed all of those issues. Had made the patch with eSVN's "quickdiff" feature. That's probably where the line ending and spaces issues came from (I'm using gedit on Linux). Made a new one from the command line this time, tested and applied happily to clean checkout.

To address the operators/functions comments, I've reconsidered my earlier position about just replacing "Project From View" when in camera view. I know that the existing improper projection while in camera view was always an annoyance in my own work, and I've noted that at least one popular tutorial on camera projection actually makes mention of it and suggests that you just have to fool around with scaling until you get it working correctly.

So, as a last solution, I've removed the separate operator, opting to pull it all under "Project from View". Now, when you choose "Project from View" when in Camera view, you get the proper camera projection. It now also works with Orthographic cameras. It's all auto-detected, so the user isn't even bothered with choosing one kind or another. If you say "Project from View" and you're in camera view, you get the camera's exact view in your UV editor.

As Matt commented originally, this is probably the best way to go. As a bonus, it doesn't require any new docs, other than stating "Project from View UV unwrap now works correctly in camera views."

The other code badness has been taken care of, too.

Patch name for this revision is: camera_project.patch%%%

%%%Okay. Addressed all of those issues. Had made the patch with eSVN's "quickdiff" feature. That's probably where the line ending and spaces issues came from (I'm using gedit on Linux). Made a new one from the command line this time, tested and applied happily to clean checkout. To address the operators/functions comments, I've reconsidered my earlier position about just replacing "Project From View" when in camera view. I know that the existing improper projection while in camera view was always an annoyance in my own work, and I've noted that at least one popular tutorial on camera projection actually makes mention of it and suggests that you just have to fool around with scaling until you get it working correctly. So, as a last solution, I've removed the separate operator, opting to pull it all under "Project from View". Now, when you choose "Project from View" when in Camera view, you get the proper camera projection. It now also works with Orthographic cameras. It's all auto-detected, so the user isn't even bothered with choosing one kind or another. If you say "Project from View" and you're in camera view, you get the camera's exact view in your UV editor. As Matt commented originally, this is probably the best way to go. As a bonus, it doesn't require any new docs, other than stating "Project from View UV unwrap now works correctly in camera views." The other code badness has been taken care of, too. Patch name for this revision is: camera_project.patch%%%

Brecht Van Lommel commented

2009-12-14 21:06:48 +01:00

%%%New patch looks fine, please commit :).%%%

Roland Hess commented

2009-12-16 01:06:08 +01:00

Changed status from 'Open' to: 'Archived'

Roland Hess closed this issue

2009-12-16 01:06:08 +01:00

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Map Camera Coordinates to UV layer #19862