Re: [Bf-committers] Render resolution question
Hi,
A very efficient way to render variable resolution for sprites is to set
render borders. Set render properties Crop on.
It's ALT+B, and via python accessible on pixel level.
-Ton-
Ton Roosendaal Blender Foundation t...@blender.orgwww.blender.org
Blender Institute Entrepotdok 57A 1018AD Amsterdam The Netherlands
On 3 Mar, 2013, at 2:57, patrick boelens wrote:
Ah, darn. =( This is indeed for personal use only; I think finding a real,
nice solution for merging scene and camera properties like this would take
quite a bit of effort and discussion on what belongs where first.
I thought about using the Py handler, but that would not update the frame
from Camera View. I could replace the Scene's render dimensions with the
Camera's, but then I would still need to manually execute an operator every
time I select a new camera (not a big issue, but still). I guess that's the
way I'll go then though.
Thanks,
Patrick
Date: Sun, 3 Mar 2013 12:44:45 +1100
From: ideasma...@gmail.com
To: bf-committers@blender.org
Subject: Re: [Bf-committers] Render resolution question
On Sun, Mar 3, 2013 at 10:55 AM, patrick boelens p_boel...@msn.com wrote:
Hello,
In working on some sprites I often find the need to change cameras and
render dimensions. I figured I'd make a small change in the source to give
cameras the option of using their own render dimensions for rendering
instead. So far I have added the resolution properties and a flag entry
'CAM_USELOCALRES' to the camera. However, I can't figure out where I would
need to switch between using the scene.render dimensions or the active
camera's ones. For my purposes it is enough to have it switch when I'm in
camera view (so that the view frame shows accordingly) and when rendering
(no need for changes in OpenGL rendering, BGE, etc.). Ideally there would
be one or two places where I could do something along the lines of:
if(scene.camera.flag CAM_USELOCALRES){dimension_x = scene.camera.resX}
else{dimension_x = scene.r.xsch} //at least I think xsch is the one here?
Any help on this would be much appreciated.
Cheers,
Patrick
Hi, don't think theres any shortcut to this, search for xsch shows 56
results, even discounting game engine and envmap there are still many
references to this.
Not sure this feature would be accepted, but think the correct way to
do this would be to replace scene.r.xsch with a function call that
takes (scene-r, scene-camera).
If this is only for your own use you could use a
'bpy.app.handlers.render_pre' python callback which sets the render
size from camera properties.
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Blender developer meeting notes - March 3, 2013
Hi all, Here are the notes from our weekly meeting in irc.freenode.net #blendercoders: 1) 2.66a update - As discussed on the bf-committers list, there's a number of important fixes that will go to the release branch, to be released as a 2.66a update. - For the next 48 hours, we'll move over the fixes to branch. Tuesday afternoon we then check status, and likely call for the builds. 2) 2.67 targets - Buildbot (builder.blender.org) for Mac is falling behind, Ton Roosendaal checks on using his system for it overnights now. - Pynode project: Lukas Toenne worked on new preview code, needs work still. It's still on target for 2.67. - Request: can someone help us to add support for Windows network UNC paths (like \\SomeHost\Share\blends\) in Blender? - Sergej Reich likes to work on Rigid Body constraints visualization and tools. If people have ideas for how to do this, start making mockups! A good reference: http://ode-wiki.org/wiki/index.php?title=Manual:_Joint_Types_and_Functions - Request: we need someone to investigate how to handle system fonts for the various languages, this handled for all OSes we support. 3) Other projects Meeting ended with discussions about migration to git. :) We need to draft a couple of steps: - Check on feasibility for it in general (including consensus for this by the core developers) - Make a migration design and plan, and who will do this - Define how to support and maintain in future. This is not a short term project, but would be nice to have the first step defined a.s.a.p. Thanks, -Ton- Ton Roosendaal Blender Foundation t...@blender.orgwww.blender.org Blender Institute Entrepotdok 57A 1018AD Amsterdam The Netherlands ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Blender developer meeting notes - March 3, 2013
Hello, - Request: can someone help us to add support for Windows network UNC paths (like \\SomeHost\Share\blends\) in Blender? The last time I checked into it there were changing all backslashes to forward slashes (both work on Windows), probably so that we could assume forward slash as the separator in other path functions. So the initial \\ then conflicts with the // we use to designate same folder as blend. There was also an assumption that all absolute paths needed to start with a drive letter and colon so we basically break the string with a bunch of over-zealous sanity checks. But I'm also pretty sure that I remember seeing at least one patch on the tracker that fixes this and allowed UNC paths... Harley ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Render resolution question
D'ow, never thought about that, thanks! (I got stubborn though and actually
hacked the camera resolutions in, but this seems like a great alternative!)
Thanks,
Patrick
From: t...@blender.org
Date: Sun, 3 Mar 2013 11:27:29 +0100
To: bf-committers@blender.org
Subject: Re: [Bf-committers] Render resolution question
Hi,
A very efficient way to render variable resolution for sprites is to set
render borders. Set render properties Crop on.
It's ALT+B, and via python accessible on pixel level.
-Ton-
Ton Roosendaal Blender Foundation t...@blender.orgwww.blender.org
Blender Institute Entrepotdok 57A 1018AD Amsterdam The Netherlands
On 3 Mar, 2013, at 2:57, patrick boelens wrote:
Ah, darn. =( This is indeed for personal use only; I think finding a real,
nice solution for merging scene and camera properties like this would take
quite a bit of effort and discussion on what belongs where first.
I thought about using the Py handler, but that would not update the frame
from Camera View. I could replace the Scene's render dimensions with the
Camera's, but then I would still need to manually execute an operator every
time I select a new camera (not a big issue, but still). I guess that's the
way I'll go then though.
Thanks,
Patrick
Date: Sun, 3 Mar 2013 12:44:45 +1100
From: ideasma...@gmail.com
To: bf-committers@blender.org
Subject: Re: [Bf-committers] Render resolution question
On Sun, Mar 3, 2013 at 10:55 AM, patrick boelens p_boel...@msn.com wrote:
Hello,
In working on some sprites I often find the need to change cameras and
render dimensions. I figured I'd make a small change in the source to
give cameras the option of using their own render dimensions for
rendering instead. So far I have added the resolution properties and a
flag entry 'CAM_USELOCALRES' to the camera. However, I can't figure out
where I would need to switch between using the scene.render dimensions or
the active camera's ones. For my purposes it is enough to have it switch
when I'm in camera view (so that the view frame shows accordingly) and
when rendering (no need for changes in OpenGL rendering, BGE, etc.).
Ideally there would be one or two places where I could do something along
the lines of:
if(scene.camera.flag CAM_USELOCALRES){dimension_x = scene.camera.resX}
else{dimension_x = scene.r.xsch} //at least I think xsch is the one here?
Any help on this would be much appreciated.
Cheers,
Patrick
Hi, don't think theres any shortcut to this, search for xsch shows 56
results, even discounting game engine and envmap there are still many
references to this.
Not sure this feature would be accepted, but think the correct way to
do this would be to replace scene.r.xsch with a function call that
takes (scene-r, scene-camera).
If this is only for your own use you could use a
'bpy.app.handlers.render_pre' python callback which sets the render
size from camera properties.
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Blender developer meeting notes - March 3, 2013
- Request: can someone help us to add support for Windows network UNC paths (like \\SomeHost\Share\blends\) in Blender? Further to this, there a patch from March 2010 that seems to have languished on the tracker... http://projects.blender.org/tracker/index.php?func=detailaid=21836group_id=9atid=127 But if you need further help or specific help or any kind of help please let me know. I have worked as a Network Administrator for large Windows domains for many years and am also quite familiar with the Windows API. Cheers, Harley ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] [Feature Request] Separate Cycles Rendered 3dView (Layer) Configuration
I would to request the following with regards to the following problem: Problem: I would like to be able to hide emitters in the 3d view you are using for editing your scene/models, while having these emitters affect the lighting in the 3d view that is set to rendered. Otherwise, the workflow becomes: Edit some stuff on your model Re-enable the layer that has your emitters to view the preview in your Rendered 3d view. While this may seem like a small thing, it's a needless inconvenience and removes the convenience of making changes in edit mode and seeing the results dynamically. Fundamentally, the issue is that the Rendered 3d View is bound to the settings of the standard 3d View panel and scene. It ought to be unbound to your actual 3d view editing panel(s) as it is in fact quite different. Then one can enable different layers for the Rendered 3d View and your standard 3d Views. There is no reason why the rendered 3d view should be bound to the editing 3d view(s) as one would often like to see the actual composited/full render as opposed to whatever subset of the scene, one is editing at the moment. Solution: I would at least like to be able to hide emitters yet still have their output be rendered in the Rendered view. One way this can be accomplished is to be able to select a different set of layers for the 3d Rendered View, or have the ability to set a set of layers for each 3d View which would be useful in and of itself. In general: I think it makes sense to be able to configure the Rendered Cycles 3d View separately and quite possibly with additional configuration parameters from the standard 3d Views used for editing as this view and its intended functionality is quite different from a standard 3d View. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Links to Online Manual
Hello, I've noticed lots of room for improvement for the Online Manual you get when you right-click on most UI items. Most of the time it takes you to a less-than-ideal page and sometimes it even fails (the layout list and scene list for examples). I would like to do some work on that, mostly just some simplification of WM_OT_doc_view_manual in wm.py and a reworking of url_manual_mapping in rna_wiki_reference.py. Is there anyone in particular I should talk to about this or should I just dive in? It looks like something that could keep me busy for a while... Harley ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Links to Online Manual
On Mon, Mar 4, 2013 at 8:16 AM, Harley Acheson harley.ache...@gmail.com wrote: Hello, I've noticed lots of room for improvement for the Online Manual you get when you right-click on most UI items. Most of the time it takes you to a less-than-ideal page and sometimes it even fails (the layout list and scene list for examples). I would like to do some work on that, mostly just some simplification of WM_OT_doc_view_manual in wm.py and a reworking of url_manual_mapping in rna_wiki_reference.py. Is there anyone in particular I should talk to about this or should I just dive in? It looks like something that could keep me busy for a while... Harley Hi Harley, It would be great to have these improved, so far I've added most of the existing URL's but there are a lot of catch-all strings like bpy.ops.view3d.* - which could be expanded on, see TODO comments. Edit 'url_manual_mapping' here: ./release/scripts/addons/modules/rna_wiki_reference.py ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] r54932 build error [Modal (aka tripod) solver rework]
I am sorry that an answer becomes slow.
I was able to build.
Thanks.
PerfectionCat.
- Original Message -
From: Sergey Sharybin sergey@gmail.com
To: PerfectionCat sindra1961reb...@yahoo.co.jp; bf-blender developers
bf-committers@blender.org
Date: 2013/3/1, Fri 17:22
Subject: Re: [Bf-committers] r54932 build error [Modal (aka tripod) solver
rework]
I believe the issue is now fixed in svn.
On Fri, Mar 1, 2013 at 12:11 PM, Sergey Sharybin sergey@gmail.com wrote:
Hrm, weird. Will look into it.
On Fri, Mar 1, 2013 at 7:10 AM, PerfectionCat sindra1961reb...@yahoo.co.jp
wrote:
Hi.
There is an error in the build.
extern\libmv\libmv\simple_pipeline\modal_solver.cc(59) : error C2719:
'marker': __declspec(align('16'))
Environment:
Windows XP/SP3 32bits
SCONS+msvc9
PerfectionCat.
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers
--
With best regards, Sergey Sharybin
--
With best regards, Sergey Sharybin
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Texture painting considerations (preparations for bratwurst merge)
Hi all, an update on this thread. Currently I am in the process of reusing paint stroke code in texture painting. The experiment is being a success but to unify the code better I will need to tweak code across other paint systems too and gather feedback. Considerations and things that I personally want to refactor are: Texture painting === * Disentangle projective and 2D painting completely. The only shared code is the stroke calculation code parts of which are duplicated in paint_stroke.c and indeed should be written once and reused on all our paint systems. This would be easier if we get rid of 3D (non-projective) mode texture painting in 3D viewport. In this mode you paint on model but result gets written in image space and will be horribly distorted in 3D view. In my opinion this is useless since we now have projective texturing for all tools (blur, smudge, clone, draw) and view mapping mode is exposed. There has been one user complaint about using pixel size of brush in 3D space which is possible in this mode but I think 3D viewport is not the editor for working in image space. On the contrary, painting on image editor is recommended and produces better feedback. * Reuse paint stroke code. This is possible currently but we do some pressure manipulation in the paint code that needs to move to the generic stroke code. Doing this in the stroke system will require reviewing all our paint systems and modifying them not to do extra conversions on the pressure. We need to define better what state the pressure values are during stroke/initialization etc. Other modes = * On almost all modes I checked (texture painting included), we use mouse coordinates in region space (the update_step functions all subtract the region coordinates from the mouse coordinates). Paint stroke code operates in screen space. I think this is only used for sculpting? Are there any objections to tweaking the code to use region space? * Pressure manipulation code should move to paint_stroke (any objections/special cases here?) * Brush texture sampling: Currently there are many methods to do this. Some are used in texture painting, 2 methods, one each for projective and 2D case and one is used for sculpting (where we convert the result to intensity). Ideally the way this should ideally operate is that we pass screen coordinate or 3D position for some brush modes to the brush texture sampling function and the function should return the corresponding texel value based on the brush settings. This should ideally be a global interface in BKE_brush. I think I could probably refactor the sculpt sampling function to something more global. I won't be able to unify the 2D paint code to use that (because input coordinates are in uv, not screen space) but this will allow us to expose texture sampling for all 3D paint modes see vertex paint, even weight paint too. Also it will allow me to implement a stencil mapping mode (like the one done by Nicholas Bishop in his ptex branch) and expose it to all 3D paint modes at once. * Almost every paint mode uses variables like first, to do first time initializations, be it tool or mode specific and last_mouse. paint stroke stores these too. Maybe they could be reused? I am waiting feedback on these from all paint system maintainers. If this is to be undertaken I could possibly do most of the code work but I'd like some good testing for corner cases that may break, which is bound to happen for certain in this kind of refactoring. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Proposed default margin increase for baked textures
This is trivial but will require yet another version patch. If others agree I could commit it wit h a value of 16. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Proposed default margin increase for baked textures
Go for it! :) On Sun, Mar 3, 2013 at 7:01 PM, Antony Riakiotakis kal...@gmail.com wrote: This is trivial but will require yet another version patch. If others agree I could commit it wit h a value of 16. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Proposed default margin increase for baked textures
On Mon, Mar 4, 2013 at 3:32 PM, Morten Mikkelsen mikkels...@gmail.com wrote: Go for it! :) On Sun, Mar 3, 2013 at 7:01 PM, Antony Riakiotakis kal...@gmail.com wrote: This is trivial but will require yet another version patch. If others agree I could commit it wit h a value of 16. Why version patch?, old files can keep their margin. Just update scene.c's bake_filter for newly added scenes, rna_scene.c's default and startup.blend. -- - Campbell ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Texture painting considerations (preparations for bratwurst merge)
Perhaps you could also look into why the default brush looks so bad for bump painting yet when air-brush is checked it looks perfect. Just a though :) Cheers, Morten. On Sun, Mar 3, 2013 at 6:17 PM, Antony Riakiotakis kal...@gmail.com wrote: Hi all, an update on this thread. Currently I am in the process of reusing paint stroke code in texture painting. The experiment is being a success but to unify the code better I will need to tweak code across other paint systems too and gather feedback. Considerations and things that I personally want to refactor are: Texture painting === * Disentangle projective and 2D painting completely. The only shared code is the stroke calculation code parts of which are duplicated in paint_stroke.c and indeed should be written once and reused on all our paint systems. This would be easier if we get rid of 3D (non-projective) mode texture painting in 3D viewport. In this mode you paint on model but result gets written in image space and will be horribly distorted in 3D view. In my opinion this is useless since we now have projective texturing for all tools (blur, smudge, clone, draw) and view mapping mode is exposed. There has been one user complaint about using pixel size of brush in 3D space which is possible in this mode but I think 3D viewport is not the editor for working in image space. On the contrary, painting on image editor is recommended and produces better feedback. * Reuse paint stroke code. This is possible currently but we do some pressure manipulation in the paint code that needs to move to the generic stroke code. Doing this in the stroke system will require reviewing all our paint systems and modifying them not to do extra conversions on the pressure. We need to define better what state the pressure values are during stroke/initialization etc. Other modes = * On almost all modes I checked (texture painting included), we use mouse coordinates in region space (the update_step functions all subtract the region coordinates from the mouse coordinates). Paint stroke code operates in screen space. I think this is only used for sculpting? Are there any objections to tweaking the code to use region space? * Pressure manipulation code should move to paint_stroke (any objections/special cases here?) * Brush texture sampling: Currently there are many methods to do this. Some are used in texture painting, 2 methods, one each for projective and 2D case and one is used for sculpting (where we convert the result to intensity). Ideally the way this should ideally operate is that we pass screen coordinate or 3D position for some brush modes to the brush texture sampling function and the function should return the corresponding texel value based on the brush settings. This should ideally be a global interface in BKE_brush. I think I could probably refactor the sculpt sampling function to something more global. I won't be able to unify the 2D paint code to use that (because input coordinates are in uv, not screen space) but this will allow us to expose texture sampling for all 3D paint modes see vertex paint, even weight paint too. Also it will allow me to implement a stencil mapping mode (like the one done by Nicholas Bishop in his ptex branch) and expose it to all 3D paint modes at once. * Almost every paint mode uses variables like first, to do first time initializations, be it tool or mode specific and last_mouse. paint stroke stores these too. Maybe they could be reused? I am waiting feedback on these from all paint system maintainers. If this is to be undertaken I could possibly do most of the code work but I'd like some good testing for corner cases that may break, which is bound to happen for certain in this kind of refactoring. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
