Re: [Bf-committers] Swiss Cheese Text Editor Refactor/Merge
The drawing would be more efficient regardless of the underlying BLF rendering due to the batching. The text editor changes aren't really dependent on the other changes. My problem is that the text editor (text_draw.c) is starting to diverge in inconvenient ways. On Tue, Apr 2, 2013 at 9:11 PM, Mitchell Stokes moguri...@gmail.com wrote: Would this also include the more efficient BLF rendering? I'm guessing the text editor changes are dependent on that? I'd really love to see BLF getting away from glBegin/glEnd. On Tue, Apr 2, 2013 at 1:28 PM, Jason Wilkins jason.a.wilk...@gmail.com wrote: During the last GSoC I made some modifications to the text editor so that it would batch text before drawing it instead of drawing on character at a time. (Since I was removing immediate mode calls from swiss-cheese, sending one character at a time as WAY too much overhead.) The recent changes to the text editor have been a bit of a nightmare to merge. The code is complicated and fragile (both mine and the original). I wanted to touch base and see if it would be OK to see about going ahead and integrating swiss-cheese's more efficient text rendering into trunk. Perhaps I could also refactor some of the code to be a little bit more maintainable as well. The reason I'm asking is I'm not sure if somebody else might have plans for this area, so I don't want to just continue as I am (merging complex changes) if it just going to be blown away. ___ 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] Slash Brushes for blender sculpting proposal
Blender has planar/trim brush. But 99% of 3d artists does not know about it. It's called Scape/Peak brush. And it has a strange icon and a strange name (imho). In Zbrush it's called Trim Brush. Here i did the video: http://www.youtube.com/watch?v=5VfUEcQrHNQfeature=youtu.be Blender does not have only Slash Brushes. I hope Nicholas Bishop understand how vital Slash Brushes and add them soon. On 03.04.2013 04:31, Mango Jambo wrote: Here is my 5 pence: Planar Brush would be a great addition: http://www.youtube.com/watch?v=3tz7na7Y75ot=1m52s http://www.youtube.com/watch?v=Auk3mKdKEwglist=PL8A06C36A85E9F361 Unfortunately the flatten brush isn't the same. Moraes Junior - aka mangojambo Animator 3D Artist +55 43 88133399 http://www.oniria.com.br On 2 April 2013 17:50, Knapp magick.c...@gmail.com wrote: ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [55733] trunk/blender/source/blender: More usage of GLSL for color managed image drawing
Hi Sergey,
This commit breaks the compositor. The input from primary renderlayer
is replaced with another renderlayer that is currently selected in the
renderlayer panel, so the expected result cannot be obtained unless the
primary renderlayer is selected.
Thanks,
IRIE Shinsuke
13/04/03, Sergey Sharybin wrote:
Revision: 55733
http://projects.blender.org/scm/viewvc.php?view=revroot=bf-blenderrevision=55733
Author: nazgul
Date: 2013-04-02 17:28:37 + (Tue, 02 Apr 2013)
Log Message:
---
More usage of GLSL for color managed image drawing
Uses GLSL for drawing image in Image Editor space.
This requires change in image_buffer_rect_update, so
original float buffer is being updated as well. This
is unlikely be something bad, but will keep an eye
on this change.
Also no byte buffer allocation happens there, this
is so because byte buffer used for display only
and in case of GLSL display such allocation and
partial update is just waste of time.
Also switched OpenGL render from using CPU color
space linearization to GLSL color space transform.
Makes OpenGL rendering pretty much faster (but
still slower than in 2.60).
internal changes:
- Added functions to setup GLSL shader for color
space conversion in colormanagement.c. Currently
conversion form a colorspace defined by a role to
linear space is implemented. Easy to extend to
other cases.
- Added helper functions to glutil.c which does
smarter image buffer draw (calling all needed OCIO
stuff, editors now could draw image buffer with a
single function call -- all the checks are done in
glutil.c).
- Also added helper function for buffer linearization
from a given role to glutil.c. Everyone now able to
linearize buffer with a single call.
This function will do nothing is GLSL routines fails
or not supported.
And one last this: this function uses offscreen
drawing, could potentially give issues on some
cards, also will keep an eye on this.
Modified Paths:
--
trunk/blender/source/blender/editors/include/BIF_glutil.h
trunk/blender/source/blender/editors/render/render_internal.c
trunk/blender/source/blender/editors/render/render_opengl.c
trunk/blender/source/blender/editors/screen/CMakeLists.txt
trunk/blender/source/blender/editors/screen/glutil.c
trunk/blender/source/blender/editors/space_clip/clip_draw.c
trunk/blender/source/blender/editors/space_image/image_draw.c
trunk/blender/source/blender/imbuf/IMB_colormanagement.h
trunk/blender/source/blender/imbuf/intern/colormanagement.c
Modified: trunk/blender/source/blender/editors/include/BIF_glutil.h
===
--- trunk/blender/source/blender/editors/include/BIF_glutil.h 2013-04-02
17:28:29 UTC (rev 55732)
+++ trunk/blender/source/blender/editors/include/BIF_glutil.h 2013-04-02
17:28:37 UTC (rev 55733)
@@ -33,6 +33,9 @@
struct rcti;
struct rctf;
+struct ImBuf;
+struct bContext;
+
void fdrawbezier(float vec[4][3]);
void fdrawline(float x1, float y1, float x2, float y2);
void fdrawbox(float x1, float y1, float x2, float y2);
@@ -223,5 +226,13 @@
} bglMats;
void bgl_get_mats(bglMats *mats);
+/* Color management helper functions for GLSL display/transform * */
+
+/* Draw imbuf on a screen, preferably using GLSL display transform */
+void glaDrawImBuf_glsl_ctx(const struct bContext *C, struct ImBuf *ibuf,
float x, float y, int zoomfilter);
+
+/* Transform buffer from role to scene linear space using GLSL OCIO
conversion */
+int glaBufferTransformFromRole_glsl(float *buffer, int width, int height,
int role);
+
#endif /* __BIF_GLUTIL_H__ */
Modified: trunk/blender/source/blender/editors/render/render_internal.c
===
--- trunk/blender/source/blender/editors/render/render_internal.c
2013-04-02 17:28:29 UTC (rev 55732)
+++ trunk/blender/source/blender/editors/render/render_internal.c
2013-04-02 17:28:37 UTC (rev 55733)
@@ -140,15 +140,23 @@
}
}
if (rectf == NULL) return;
-
- if (ibuf-rect == NULL)
- imb_addrectImBuf(ibuf);
rectf += 4 * (rr-rectx * ymin + xmin);
- IMB_partial_display_buffer_update(ibuf, rectf, NULL, rr-rectx, rxmin,
rymin,
- scene-view_settings,
scene-display_settings,
- rxmin, rymin, rxmin + xmax, rymin +
ymax, TRUE);
+ if (ibuf-rect) {
+ IMB_partial_display_buffer_update(ibuf, rectf, NULL, rr-rectx,
rxmin, rymin,
+ scene-view_settings,
scene-display_settings,
+ rxmin, rymin, rxmin + xmax,
rymin + ymax, TRUE);
+ }
+
+ /* update float buffer as
Re: [Bf-committers] Swiss Cheese Text Editor Refactor/Merge
Would it work with multicolumn characters which were recently added by http://projects.blender.org/tracker/index.php?func=detailaid=34373group_id=9atid=127? On Wed, Apr 3, 2013 at 11:34 AM, Jason Wilkins jason.a.wilk...@gmail.comwrote: The drawing would be more efficient regardless of the underlying BLF rendering due to the batching. The text editor changes aren't really dependent on the other changes. My problem is that the text editor (text_draw.c) is starting to diverge in inconvenient ways. On Tue, Apr 2, 2013 at 9:11 PM, Mitchell Stokes moguri...@gmail.com wrote: Would this also include the more efficient BLF rendering? I'm guessing the text editor changes are dependent on that? I'd really love to see BLF getting away from glBegin/glEnd. On Tue, Apr 2, 2013 at 1:28 PM, Jason Wilkins jason.a.wilk...@gmail.com wrote: During the last GSoC I made some modifications to the text editor so that it would batch text before drawing it instead of drawing on character at a time. (Since I was removing immediate mode calls from swiss-cheese, sending one character at a time as WAY too much overhead.) The recent changes to the text editor have been a bit of a nightmare to merge. The code is complicated and fragile (both mine and the original). I wanted to touch base and see if it would be OK to see about going ahead and integrating swiss-cheese's more efficient text rendering into trunk. Perhaps I could also refactor some of the code to be a little bit more maintainable as well. The reason I'm asking is I'm not sure if somebody else might have plans for this area, so I don't want to just continue as I am (merging complex changes) if it just going to be blown away. ___ 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] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [55733] trunk/blender/source/blender: More usage of GLSL for color managed image drawing
This commit does nothing to do with compositor.
Please report a bug to the tracker and attach .blend file which
demonstrates the issue.
On Wed, Apr 3, 2013 at 1:50 PM, IRIE Shinsuke irieshins...@yahoo.co.jpwrote:
Hi Sergey,
This commit breaks the compositor. The input from primary renderlayer
is replaced with another renderlayer that is currently selected in the
renderlayer panel, so the expected result cannot be obtained unless the
primary renderlayer is selected.
Thanks,
IRIE Shinsuke
13/04/03, Sergey Sharybin wrote:
Revision: 55733
http://projects.blender.org/scm/viewvc.php?view=revroot=bf-blenderrevision=55733
Author: nazgul
Date: 2013-04-02 17:28:37 + (Tue, 02 Apr 2013)
Log Message:
---
More usage of GLSL for color managed image drawing
Uses GLSL for drawing image in Image Editor space.
This requires change in image_buffer_rect_update, so
original float buffer is being updated as well. This
is unlikely be something bad, but will keep an eye
on this change.
Also no byte buffer allocation happens there, this
is so because byte buffer used for display only
and in case of GLSL display such allocation and
partial update is just waste of time.
Also switched OpenGL render from using CPU color
space linearization to GLSL color space transform.
Makes OpenGL rendering pretty much faster (but
still slower than in 2.60).
internal changes:
- Added functions to setup GLSL shader for color
space conversion in colormanagement.c. Currently
conversion form a colorspace defined by a role to
linear space is implemented. Easy to extend to
other cases.
- Added helper functions to glutil.c which does
smarter image buffer draw (calling all needed OCIO
stuff, editors now could draw image buffer with a
single function call -- all the checks are done in
glutil.c).
- Also added helper function for buffer linearization
from a given role to glutil.c. Everyone now able to
linearize buffer with a single call.
This function will do nothing is GLSL routines fails
or not supported.
And one last this: this function uses offscreen
drawing, could potentially give issues on some
cards, also will keep an eye on this.
Modified Paths:
--
trunk/blender/source/blender/editors/include/BIF_glutil.h
trunk/blender/source/blender/editors/render/render_internal.c
trunk/blender/source/blender/editors/render/render_opengl.c
trunk/blender/source/blender/editors/screen/CMakeLists.txt
trunk/blender/source/blender/editors/screen/glutil.c
trunk/blender/source/blender/editors/space_clip/clip_draw.c
trunk/blender/source/blender/editors/space_image/image_draw.c
trunk/blender/source/blender/imbuf/IMB_colormanagement.h
trunk/blender/source/blender/imbuf/intern/colormanagement.c
Modified: trunk/blender/source/blender/editors/include/BIF_glutil.h
===
--- trunk/blender/source/blender/editors/include/BIF_glutil.h 2013-04-02
17:28:29 UTC (rev 55732)
+++ trunk/blender/source/blender/editors/include/BIF_glutil.h 2013-04-02
17:28:37 UTC (rev 55733)
@@ -33,6 +33,9 @@
struct rcti;
struct rctf;
+struct ImBuf;
+struct bContext;
+
void fdrawbezier(float vec[4][3]);
void fdrawline(float x1, float y1, float x2, float y2);
void fdrawbox(float x1, float y1, float x2, float y2);
@@ -223,5 +226,13 @@
} bglMats;
void bgl_get_mats(bglMats *mats);
+/* Color management helper functions for GLSL display/transform
* */
+
+/* Draw imbuf on a screen, preferably using GLSL display transform */
+void glaDrawImBuf_glsl_ctx(const struct bContext *C, struct ImBuf
*ibuf, float x, float y, int zoomfilter);
+
+/* Transform buffer from role to scene linear space using GLSL OCIO
conversion */
+int glaBufferTransformFromRole_glsl(float *buffer, int width, int
height, int role);
+
#endif /* __BIF_GLUTIL_H__ */
Modified: trunk/blender/source/blender/editors/render/render_internal.c
===
--- trunk/blender/source/blender/editors/render/render_internal.c
2013-04-02 17:28:29 UTC (rev 55732)
+++ trunk/blender/source/blender/editors/render/render_internal.c
2013-04-02 17:28:37 UTC (rev 55733)
@@ -140,15 +140,23 @@
}
}
if (rectf == NULL) return;
-
- if (ibuf-rect == NULL)
- imb_addrectImBuf(ibuf);
rectf += 4 * (rr-rectx * ymin + xmin);
- IMB_partial_display_buffer_update(ibuf, rectf, NULL, rr-rectx,
rxmin, rymin,
- scene-view_settings,
scene-display_settings,
- rxmin, rymin, rxmin + xmax,
rymin + ymax, TRUE);
+ if (ibuf-rect) {
+
Re: [Bf-committers] Slash Brushes for blender sculpting proposal
Well, don't take my word too literally, I mean we already have some sort of duplication in brushes. For instance in vertex paint we have add/subtract etc brushes. All are essentially the same tool with a different blend factor. So we already have some duplication for brushes in blender (these even include a default icon). If it's SO standard and wanted there is precedent to include such a brush but I can easily imagine a beginner deleting the texture when browsing through textures for materials and then complaining why the brush does not work, or experts wondering why there's an extra texture in the default blend :p ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [55733] trunk/blender/source/blender: More usage of GLSL for color managed image drawing
Submitted a bug report in the tracker: http://projects.blender.org/tracker/index.php?func=detailaid=34854group_id=9atid=498 IRIE Shinsuke 13/04/03, Sergey Sharybin wrote: This commit does nothing to do with compositor. Please report a bug to the tracker and attach .blend file which demonstrates the issue. On Wed, Apr 3, 2013 at 1:50 PM, IRIE Shinsuke irieshins...@yahoo.co.jpwrote: Hi Sergey, This commit breaks the compositor. The input from primary renderlayer is replaced with another renderlayer that is currently selected in the renderlayer panel, so the expected result cannot be obtained unless the primary renderlayer is selected. Thanks, IRIE Shinsuke 13/04/03, Sergey Sharybin wrote: Revision: 55733 http://projects.blender.org/scm/viewvc.php?view=revroot=bf-blenderrevision=55733 Author: nazgul Date: 2013-04-02 17:28:37 + (Tue, 02 Apr 2013) Log Message: --- More usage of GLSL for color managed image drawing Uses GLSL for drawing image in Image Editor space. This requires change in image_buffer_rect_update, so original float buffer is being updated as well. This is unlikely be something bad, but will keep an eye on this change. Also no byte buffer allocation happens there, this is so because byte buffer used for display only and in case of GLSL display such allocation and partial update is just waste of time. Also switched OpenGL render from using CPU color space linearization to GLSL color space transform. Makes OpenGL rendering pretty much faster (but still slower than in 2.60). internal changes: - Added functions to setup GLSL shader for color space conversion in colormanagement.c. Currently conversion form a colorspace defined by a role to linear space is implemented. Easy to extend to other cases. - Added helper functions to glutil.c which does smarter image buffer draw (calling all needed OCIO stuff, editors now could draw image buffer with a single function call -- all the checks are done in glutil.c). - Also added helper function for buffer linearization from a given role to glutil.c. Everyone now able to linearize buffer with a single call. This function will do nothing is GLSL routines fails or not supported. And one last this: this function uses offscreen drawing, could potentially give issues on some cards, also will keep an eye on this. Modified Paths: -- trunk/blender/source/blender/editors/include/BIF_glutil.h trunk/blender/source/blender/editors/render/render_internal.c trunk/blender/source/blender/editors/render/render_opengl.c trunk/blender/source/blender/editors/screen/CMakeLists.txt trunk/blender/source/blender/editors/screen/glutil.c trunk/blender/source/blender/editors/space_clip/clip_draw.c trunk/blender/source/blender/editors/space_image/image_draw.c trunk/blender/source/blender/imbuf/IMB_colormanagement.h trunk/blender/source/blender/imbuf/intern/colormanagement.c Modified: trunk/blender/source/blender/editors/include/BIF_glutil.h === --- trunk/blender/source/blender/editors/include/BIF_glutil.h 2013-04-02 17:28:29 UTC (rev 55732) +++ trunk/blender/source/blender/editors/include/BIF_glutil.h 2013-04-02 17:28:37 UTC (rev 55733) @@ -33,6 +33,9 @@ struct rcti; struct rctf; +struct ImBuf; +struct bContext; + void fdrawbezier(float vec[4][3]); void fdrawline(float x1, float y1, float x2, float y2); void fdrawbox(float x1, float y1, float x2, float y2); @@ -223,5 +226,13 @@ } bglMats; void bgl_get_mats(bglMats *mats); +/* Color management helper functions for GLSL display/transform * */ + +/* Draw imbuf on a screen, preferably using GLSL display transform */ +void glaDrawImBuf_glsl_ctx(const struct bContext *C, struct ImBuf *ibuf, float x, float y, int zoomfilter); + +/* Transform buffer from role to scene linear space using GLSL OCIO conversion */ +int glaBufferTransformFromRole_glsl(float *buffer, int width, int height, int role); + #endif /* __BIF_GLUTIL_H__ */ Modified: trunk/blender/source/blender/editors/render/render_internal.c === --- trunk/blender/source/blender/editors/render/render_internal.c 2013-04-02 17:28:29 UTC (rev 55732) +++ trunk/blender/source/blender/editors/render/render_internal.c 2013-04-02 17:28:37 UTC (rev 55733) @@ -140,15 +140,23 @@ } } if (rectf == NULL) return; - - if (ibuf-rect == NULL) - imb_addrectImBuf(ibuf); rectf += 4 * (rr-rectx * ymin + xmin); - IMB_partial_display_buffer_update(ibuf, rectf, NULL, rr-rectx, rxmin, rymin, - scene-view_settings, scene-display_settings, - rxmin,
Re: [Bf-committers] Slash Brushes for blender sculpting proposal
I don't care how you implement it. I just want to have it by default. As there was a talk about assets... Blender really has a lack of assets implementation. On 03.04.2013 12:14, Antony Riakiotakis wrote: Well, don't take my word too literally, I mean we already have some sort of duplication in brushes. For instance in vertex paint we have add/subtract etc brushes. All are essentially the same tool with a different blend factor. So we already have some duplication for brushes in blender (these even include a default icon). If it's SO standard and wanted there is precedent to include such a brush but I can easily imagine a beginner deleting the texture when browsing through textures for materials and then complaining why the brush does not work, or experts wondering why there's an extra texture in the default blend :p ___ 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] Swiss Cheese Text Editor Refactor/Merge
After digging into this problem a bit I got frustrated. The new blf_font_draw_mono code determines how much wide text is while drawing it, which isn't really compatible with batching up as much text as possible before drawing it. I guess I won't be able to sort this out in 45 minutes like I'd hoped. On Tue, Apr 2, 2013 at 3:28 PM, Jason Wilkins jason.a.wilk...@gmail.comwrote: During the last GSoC I made some modifications to the text editor so that it would batch text before drawing it instead of drawing on character at a time. (Since I was removing immediate mode calls from swiss-cheese, sending one character at a time as WAY too much overhead.) The recent changes to the text editor have been a bit of a nightmare to merge. The code is complicated and fragile (both mine and the original). I wanted to touch base and see if it would be OK to see about going ahead and integrating swiss-cheese's more efficient text rendering into trunk. Perhaps I could also refactor some of the code to be a little bit more maintainable as well. The reason I'm asking is I'm not sure if somebody else might have plans for this area, so I don't want to just continue as I am (merging complex changes) if it just going to be blown away. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Swiss Cheese Text Editor Refactor/Merge
This is what I'm talking about. The multicolumn character feature modifies code that has a basic design flaw. I've fixed that flaw already, but it isn't in trunk. I'm trying to puzzle out how to fix it again, but I need to make sure I'm not stomping on any toes. On Wed, Apr 3, 2013 at 2:58 AM, Lockal S lockals...@gmail.com wrote: Would it work with multicolumn characters which were recently added by http://projects.blender.org/tracker/index.php?func=detailaid=34373group_id=9atid=127 ? On Wed, Apr 3, 2013 at 11:34 AM, Jason Wilkins jason.a.wilk...@gmail.com wrote: The drawing would be more efficient regardless of the underlying BLF rendering due to the batching. The text editor changes aren't really dependent on the other changes. My problem is that the text editor (text_draw.c) is starting to diverge in inconvenient ways. On Tue, Apr 2, 2013 at 9:11 PM, Mitchell Stokes moguri...@gmail.com wrote: Would this also include the more efficient BLF rendering? I'm guessing the text editor changes are dependent on that? I'd really love to see BLF getting away from glBegin/glEnd. On Tue, Apr 2, 2013 at 1:28 PM, Jason Wilkins jason.a.wilk...@gmail.com wrote: During the last GSoC I made some modifications to the text editor so that it would batch text before drawing it instead of drawing on character at a time. (Since I was removing immediate mode calls from swiss-cheese, sending one character at a time as WAY too much overhead.) The recent changes to the text editor have been a bit of a nightmare to merge. The code is complicated and fragile (both mine and the original). I wanted to touch base and see if it would be OK to see about going ahead and integrating swiss-cheese's more efficient text rendering into trunk. Perhaps I could also refactor some of the code to be a little bit more maintainable as well. The reason I'm asking is I'm not sure if somebody else might have plans for this area, so I don't want to just continue as I am (merging complex changes) if it just going to be blown away. ___ 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 ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Slash Brushes for blender sculpting proposal
This would be a non-issue if the template and asset .blend system was in place already. So, maybe a better use of our time would be to spend it gathering assets together for a sculpting template, instead of trying to head-butt changes into the defaults, which always seem to end with a big conversation going nowhere. On 3 April 2013 10:45, Paul Geraskin paulgeras...@gmail.com wrote: I don't care how you implement it. I just want to have it by default. As there was a talk about assets... Blender really has a lack of assets implementation. On 03.04.2013 12:14, Antony Riakiotakis wrote: Well, don't take my word too literally, I mean we already have some sort of duplication in brushes. For instance in vertex paint we have add/subtract etc brushes. All are essentially the same tool with a different blend factor. So we already have some duplication for brushes in blender (these even include a default icon). If it's SO standard and wanted there is precedent to include such a brush but I can easily imagine a beginner deleting the texture when browsing through textures for materials and then complaining why the brush does not work, or experts wondering why there's an extra texture in the default blend :p ___ 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] Slash Brushes for blender sculpting proposal
You, personally, can make the brush and have it by default. Make a brush, fake user, save as default blend. So of course you don't care :). Don't take this as rejection, this is a really cool setup you have there but the problem of doing this right is important too and since this is the developer's mailing list, implementation discussions are on topic. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Slash Brushes for blender sculpting proposal
I can make it easily. But you forgot about other 1 3d artists who even don't that that it's possible. This considers the development too. I open Zbrush - i see about 5 different slash brushes. I open Mudbox - i see 2 Slash brushes. I open blender - i see no slash brushes. I just want blender to become more professional and easy to use tool. Just a question: How many good sculpts did you see made by blender? I saw about 5 during 3 moths made in blender. And i saw about 300 during 3 moths made in zbrush. I want to see more good sculpts in blender. And only you(devs) can help 3d artists with it. I don't want to hurt anyone. I just told my point. On 03.04.2013 13:23, Antony Riakiotakis wrote: You, personally, can make the brush and have it by default. Make a brush, fake user, save as default blend. So of course you don't care :). Don't take this as rejection, this is a really cool setup you have there but the problem of doing this right is important too and since this is the developer's mailing list, implementation discussions are on topic. ___ 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] Swiss Cheese Text Editor Refactor/Merge
Hi Jason, The multi-column character support is what I've implemented. If your change breaks something, I maybe can help you to fix it. Anyway, I'm not planning to change the text editor drastically in the near future. IRIE Shinsuke 13/04/03, Jason Wilkins wrote: This is what I'm talking about. The multicolumn character feature modifies code that has a basic design flaw. I've fixed that flaw already, but it isn't in trunk. I'm trying to puzzle out how to fix it again, but I need to make sure I'm not stomping on any toes. On Wed, Apr 3, 2013 at 2:58 AM, Lockal S lockals...@gmail.com wrote: Would it work with multicolumn characters which were recently added by http://projects.blender.org/tracker/index.php?func=detailaid=34373group_id=9atid=127 ? On Wed, Apr 3, 2013 at 11:34 AM, Jason Wilkins jason.a.wilk...@gmail.com wrote: The drawing would be more efficient regardless of the underlying BLF rendering due to the batching. The text editor changes aren't really dependent on the other changes. My problem is that the text editor (text_draw.c) is starting to diverge in inconvenient ways. On Tue, Apr 2, 2013 at 9:11 PM, Mitchell Stokes moguri...@gmail.com wrote: Would this also include the more efficient BLF rendering? I'm guessing the text editor changes are dependent on that? I'd really love to see BLF getting away from glBegin/glEnd. On Tue, Apr 2, 2013 at 1:28 PM, Jason Wilkins jason.a.wilk...@gmail.com wrote: During the last GSoC I made some modifications to the text editor so that it would batch text before drawing it instead of drawing on character at a time. (Since I was removing immediate mode calls from swiss-cheese, sending one character at a time as WAY too much overhead.) The recent changes to the text editor have been a bit of a nightmare to merge. The code is complicated and fragile (both mine and the original). I wanted to touch base and see if it would be OK to see about going ahead and integrating swiss-cheese's more efficient text rendering into trunk. Perhaps I could also refactor some of the code to be a little bit more maintainable as well. The reason I'm asking is I'm not sure if somebody else might have plans for this area, so I don't want to just continue as I am (merging complex changes) if it just going to be blown away. ___ 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 ___ 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] About instant crash when reloading python (F8)
Hi devs,
Posting this to keep track of what I have found so far, and see whether
others devs have ideas about the problem...
So, this is about instant segfault that is regularly reported by users
when trying to reload python code with F8 shortcut. I finally managed to
find (I think!) what is the issue: it appears when one or more addons
which define keymaps are enabled.
Now, I gdb-tracked it down to WM_keyconfig_update(), wm_keymap.c:1104.
Here, kmdi-add_item-ptr PointerRNA seems to be corrupted some way,
just after reload (at least its type (StructRNA) member, sometimes it
has a NULL identifier, and invalid description/translation_context
pointers, sometimes it points to a wrong type...).
I tried to force this pointer to NULL (see *ugly* patch attached, or
http://www.pasteall.org/41030/diff ), and everything seems to work fine
again.
Questions are: why those PointerRNA become corrupted? Because of py
reloading, which deletes/recreates some RNA structs (operators, menus,
etc.)?
And would that kind of patch be considered as acceptable?
Best regards,
Bastien
Index: source/blender/windowmanager/intern/wm_keymap.c
===
--- source/blender/windowmanager/intern/wm_keymap.c (révision 55756)
+++ source/blender/windowmanager/intern/wm_keymap.c (copie de travail)
@@ -1100,10 +1100,20 @@
for (km = U.user_keymaps.first; km; km = km-next) {
if ((km-flag KEYMAP_MODAL) == 0) {
for (kmdi = km-diff_items.first; kmdi; kmdi = kmdi-next) {
-if (kmdi-add_item)
+if (kmdi-add_item) {
+ if (kmdi-add_item-ptr) {
+ MEM_freeN(kmdi-add_item-ptr);
+ kmdi-add_item-ptr = NULL;
+ }
wm_keymap_item_properties_set(kmdi-add_item);
-if (kmdi-remove_item)
+}
+if (kmdi-remove_item) {
+ if (kmdi-remove_item-ptr) {
+ MEM_freeN(kmdi-remove_item-ptr);
+ kmdi-remove_item-ptr = NULL;
+ }
wm_keymap_item_properties_set(kmdi-remove_item);
+}
}
for (kmi = km-items.first; kmi; kmi = kmi-next)
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Stereoscopy Implementation Proposal
Sugestion: It would be nice if we can manage to set an existing camera to be left or right, and don't me moved at all when we setup planes in stereoscopy. This would be very usefull to convert old project to 3d, so we can keep old renders as left or right and just render one new camera. If the addon turns old camera into center, this is not possible and we have to render every thing allover again. -- View this message in context: http://blender.45788.n6.nabble.com/Stereoscopy-Implementation-Proposal-tp106106p106425.html Sent from the Bf-committers mailing list archive at Nabble.com. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Swiss Cheese Text Editor Refactor/Merge
Great. I did manage to merge the two versions after a lot of thought. However, I need to spend some time refining and testing it before I commit any changes. On Wed, Apr 3, 2013 at 8:28 AM, IRIE Shinsuke irieshins...@yahoo.co.jpwrote: Hi Jason, The multi-column character support is what I've implemented. If your change breaks something, I maybe can help you to fix it. Anyway, I'm not planning to change the text editor drastically in the near future. IRIE Shinsuke 13/04/03, Jason Wilkins wrote: This is what I'm talking about. The multicolumn character feature modifies code that has a basic design flaw. I've fixed that flaw already, but it isn't in trunk. I'm trying to puzzle out how to fix it again, but I need to make sure I'm not stomping on any toes. On Wed, Apr 3, 2013 at 2:58 AM, Lockal S lockals...@gmail.com wrote: Would it work with multicolumn characters which were recently added by http://projects.blender.org/tracker/index.php?func=detailaid=34373group_id=9atid=127 ? On Wed, Apr 3, 2013 at 11:34 AM, Jason Wilkins jason.a.wilk...@gmail.com wrote: The drawing would be more efficient regardless of the underlying BLF rendering due to the batching. The text editor changes aren't really dependent on the other changes. My problem is that the text editor (text_draw.c) is starting to diverge in inconvenient ways. On Tue, Apr 2, 2013 at 9:11 PM, Mitchell Stokes moguri...@gmail.com wrote: Would this also include the more efficient BLF rendering? I'm guessing the text editor changes are dependent on that? I'd really love to see BLF getting away from glBegin/glEnd. On Tue, Apr 2, 2013 at 1:28 PM, Jason Wilkins jason.a.wilk...@gmail.com wrote: During the last GSoC I made some modifications to the text editor so that it would batch text before drawing it instead of drawing on character at a time. (Since I was removing immediate mode calls from swiss-cheese, sending one character at a time as WAY too much overhead.) The recent changes to the text editor have been a bit of a nightmare to merge. The code is complicated and fragile (both mine and the original). I wanted to touch base and see if it would be OK to see about going ahead and integrating swiss-cheese's more efficient text rendering into trunk. Perhaps I could also refactor some of the code to be a little bit more maintainable as well. The reason I'm asking is I'm not sure if somebody else might have plans for this area, so I don't want to just continue as I am (merging complex changes) if it just going to be blown away. ___ 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 ___ 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
