[Bf-committers] Text rendering
Hi all quick question is there anyway of reinitialising the UI font's system during runtime. i have been working on making text AA an optional and made it in such a way that other options should be easy to add, however i have run into the last hurdle, the option requires the user to save the default then restart blender, this is not ideal, it should update as soon as the option is changed. the notifier NC_SCREEN is not High enough since font drawing is so deeply rooted and its not handled in NC_WINDOW and NC_WM. i would like to make a new notifier for this but there is really no functions open to reinitialise fonts. If any one can help please do what i have so far http://www.pasteall.org/17136/diff ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] S-DNA and Changes
Hi Leo,
Then you can have one strip with an fcurve to map from VSE output frames
to scene frames:
Strip 1: Scene, frames 1-20, with an fcurve that maps from VSE frames
(iterated over using next()) to scene frames. It covers frames 1-219 in
the VSE.
If I may modify your code a little:
class scene_iterator : public iterator {
public:
Frame next () {
// fcurves go in map_vse_frame_to_cfra
float cfra = map_vse_frame_to_cfra (nextFrame);
setup_render(cfra);
++nextFrame;
return render();
}
int nextFrame;
}
and again, that doesn't work with fcurves and gets really nasty
with stacked speed effects.
map_vse_frame_to_cfra() is *really* a non-trivial function!
VSE only sees a sequence of discrete frames
uhm, why is that exactly the case? In fact, currently it renders
internally with floats.
- which is precisely what its domain model should look like,
because video editing is about time-discrete sequences, not continuous.
again, why? The point behind making cfra continous was, that the *input*
strip can make it's best afford to do inter-frame interpolation or do
in-between rendering.
It depends heavily on the *input* strip, how that is done best.
So: no, I *strongly* disagree with your opinion, that the VSE sees a
sequence of discrete frames. In fact, it doesn't!
The Blender scene is a continuous simulation - having a float cfra
makes sense, because time is continuous there. In the VSE the domain
objects are discrete in time. Having a float cfra makes no sense.
as stated above, I disagree.
Which brings me to the point: what was the sense in dropping the random
access interface again?
The imbuf reader has also a random access interface, but internally keeps
track of the last fetched frame and only reseeks on demand.
It is always possible to wrap a sequential interface in a random-access
interface, or vice versa. The purpose of dropping the random access
interface was to be able to write code that didn't have to deal with two
cases - you'd know that you'll always be expected to produce the next
frame, and can code for that. Less to write, less to go wrong.
uhm, you always will need a fetch() and a seek() function, so where
exactly does your idea make things simpler?
Clients of the code know that they can iterate over *every* frame in the
sequence just by calling next(). With a random access interface -
especially one that uses floats for indexing - you'll always worry if
you missed a frame, or got a duplicate, thanks to rounding errors.
uhm, as stated above, next() isn't really defined in your sense.
You can define a version, that does CFRA + 1 if you like. If that is
really helpfull is another question.
In fact, the next cfra for a given track will be defined by the topmost
speed effect fcurve and then calculated down the stack. That won't break
your initial idea of changing the order in which frame calculation takes
place, it only reflects the fact, that next() isn't that easy to calculate
if you do retiming in a creative way.
So: yes, next() won't be easy to calculate in advance for a given track,
but yes: that is a fundamental problem, if we allow stacked retiming with
curves. Even if you do retiming with simple factors, you will run into the
problem, that if the user speeds up a track with say a factor of 100 you
probably don't want to blend *all* input frames into the output frame but
limit the sampling to say 10 inbetween frames. (That's the way Blender
2.49 does it and Blender 2.5 will do it soon using the new SeqRenderData
parameters.)
Cheers,
Peter
Peter Schlaile
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Have you seen this?? How to improve Blender
I saw a link posted by Andrew showing a first online prorotype of the home page : http://69.164.205.151/blender/ On Fri, Nov 26, 2010 at 5:22 AM, Prashant Sohani prashant.soh...@gmail.comwrote: Well.. I am reviving this old thread.. The points raised in the presentation were very valid; I think it's high time we act on some of them. Has anybody a ready new home page for blender.org? If not, I volunteer to redesign the homepage of Blender and any other parts that may be wanting a complete overhaul. I have reasonably good skills in web development. (I am just done with an exceptionally heavy semester, and have a month's holiday ahead of me.) And of course, anybody else willing to volunteer, is welcome as well :) I'll create my own version on my website, and I'll post the link(s) in a new thread.. people may comment on it etc. In the meanwhile, let's start brainstorming about what we can do about the other points raised in the same presentation. ___ 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] GPL-LGPL-extension discussion closed
Hi, All opinions have been heard now. I will first talk to the key contributors to Blender to have them aligned on a good proposal for how to tackle the topic, and will come with a proposal to review here before we move to 2.6. In the meantime we happily go back bug fixing and making 2.5x awesome! :) -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] Have you seen this?? How to improve Blender
Now that is slick. /LS On 2010-11-26 11:13, Steren wrote: I saw a link posted by Andrew showing a first online prorotype of the home page : http://69.164.205.151/blender/ On Fri, Nov 26, 2010 at 5:22 AM, Prashant Sohani prashant.soh...@gmail.comwrote: Well.. I am reviving this old thread.. The points raised in the presentation were very valid; I think it's high time we act on some of them. Has anybody a ready new home page for blender.org? If not, I volunteer to redesign the homepage of Blender and any other parts that may be wanting a complete overhaul. I have reasonably good skills in web development. (I am just done with an exceptionally heavy semester, and have a month's holiday ahead of me.) And of course, anybody else willing to volunteer, is welcome as well :) I'll create my own version on my website, and I'll post the link(s) in a new thread.. people may comment on it etc. In the meanwhile, let's start brainstorming about what we can do about the other points raised in the same presentation. ___ 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] S-DNA and Changes
Hi Peter,
you raise some very good points, and I'll have to go back to the drawing
board for a moment.
For example: How do you play a movie backwards? Not easy with a
next()-style interface.
It's going to take a little while, though, because the next() style
interface makes some other things like image stabilization and object
tracking much easier.
One question, though:
map_vse_frame_to_cfra() is *really* a non-trivial function!
How? Isn't it just a fcurve.evaluate (frame)? Or is it the speed control
strips that make it non-trivial?
/LS
On 2010-11-26 10:25, Peter Schlaile wrote:
Hi Leo,
Then you can have one strip with an fcurve to map from VSE output frames
to scene frames:
Strip 1: Scene, frames 1-20, with an fcurve that maps from VSE frames
(iterated over using next()) to scene frames. It covers frames 1-219 in
the VSE.
If I may modify your code a little:
class scene_iterator : public iterator {
public:
Frame next () {
// fcurves go in map_vse_frame_to_cfra
float cfra = map_vse_frame_to_cfra (nextFrame);
setup_render(cfra);
++nextFrame;
return render();
}
int nextFrame;
}
and again, that doesn't work with fcurves and gets really nasty
with stacked speed effects.
map_vse_frame_to_cfra() is *really* a non-trivial function!
VSE only sees a sequence of discrete frames
uhm, why is that exactly the case? In fact, currently it renders
internally with floats.
- which is precisely what its domain model should look like,
because video editing is about time-discrete sequences, not continuous.
again, why? The point behind making cfra continous was, that the *input*
strip can make it's best afford to do inter-frame interpolation or do
in-between rendering.
It depends heavily on the *input* strip, how that is done best.
So: no, I *strongly* disagree with your opinion, that the VSE sees a
sequence of discrete frames. In fact, it doesn't!
The Blender scene is a continuous simulation - having a float cfra
makes sense, because time is continuous there. In the VSE the domain
objects are discrete in time. Having a float cfra makes no sense.
as stated above, I disagree.
Which brings me to the point: what was the sense in dropping the random
access interface again?
The imbuf reader has also a random access interface, but internally keeps
track of the last fetched frame and only reseeks on demand.
It is always possible to wrap a sequential interface in a random-access
interface, or vice versa. The purpose of dropping the random access
interface was to be able to write code that didn't have to deal with two
cases - you'd know that you'll always be expected to produce the next
frame, and can code for that. Less to write, less to go wrong.
uhm, you always will need a fetch() and a seek() function, so where
exactly does your idea make things simpler?
Clients of the code know that they can iterate over *every* frame in the
sequence just by calling next(). With a random access interface -
especially one that uses floats for indexing - you'll always worry if
you missed a frame, or got a duplicate, thanks to rounding errors.
uhm, as stated above, next() isn't really defined in your sense.
You can define a version, that does CFRA + 1 if you like. If that is
really helpfull is another question.
In fact, the next cfra for a given track will be defined by the topmost
speed effect fcurve and then calculated down the stack. That won't break
your initial idea of changing the order in which frame calculation takes
place, it only reflects the fact, that next() isn't that easy to calculate
if you do retiming in a creative way.
So: yes, next() won't be easy to calculate in advance for a given track,
but yes: that is a fundamental problem, if we allow stacked retiming with
curves. Even if you do retiming with simple factors, you will run into the
problem, that if the user speeds up a track with say a factor of 100 you
probably don't want to blend *all* input frames into the output frame but
limit the sampling to say 10 inbetween frames. (That's the way Blender
2.49 does it and Blender 2.5 will do it soon using the new SeqRenderData
parameters.)
Cheers,
Peter
Peter Schlaile
___
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] Have you seen this?? How to improve Blender
Slick indeed. I do think that the Free Download part should be emphasised a bit more though, slightly bigger font should do it. Otherwise, looking cool :) On 2010/11/26 12:46 PM, Leo Sutic wrote: Now that is slick. /LS On 2010-11-26 11:13, Steren wrote: I saw a link posted by Andrew showing a first online prorotype of the home page : http://69.164.205.151/blender/ On Fri, Nov 26, 2010 at 5:22 AM, Prashant Sohani prashant.soh...@gmail.comwrote: Well.. I am reviving this old thread.. The points raised in the presentation were very valid; I think it's high time we act on some of them. Has anybody a ready new home page for blender.org? If not, I volunteer to redesign the homepage of Blender and any other parts that may be wanting a complete overhaul. I have reasonably good skills in web development. (I am just done with an exceptionally heavy semester, and have a month's holiday ahead of me.) And of course, anybody else willing to volunteer, is welcome as well :) I'll create my own version on my website, and I'll post the link(s) in a new thread.. people may comment on it etc. In the meanwhile, let's start brainstorming about what we can do about the other points raised in the same presentation. ___ 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 [33327] trunk/blender/source/blender/gpu/ intern/gpu_draw.c: freeing all free GPU buffers every frame could be a performance issue
Hi, This was a bugfix to solve crashes when freeing VBO's from other threads, to do it inside the main thread instead. These buffers were previously freed immediately in GPU_buffer_free, this call just delayed them. It doesn't do any more freeing than before as far as I can see, the check MAX_FREE_GPU_BUFFERS is still there. Brecht. On Fri, Nov 26, 2010 at 12:20 PM, Lukas Steiblys imb...@imbusy.org wrote: Revision: 33327 http://projects.blender.org/plugins/scmsvn/viewcvs.php?view=revroot=bf-blenderrevision=33327 Author: imbusy Date: 2010-11-26 12:20:03 +0100 (Fri, 26 Nov 2010) Log Message: --- freeing all free GPU buffers every frame could be a performance issue and is not necessary Modified Paths: -- trunk/blender/source/blender/gpu/intern/gpu_draw.c Modified: trunk/blender/source/blender/gpu/intern/gpu_draw.c === --- trunk/blender/source/blender/gpu/intern/gpu_draw.c 2010-11-26 03:58:31 UTC (rev 33326) +++ trunk/blender/source/blender/gpu/intern/gpu_draw.c 2010-11-26 11:20:03 UTC (rev 33327) @@ -810,7 +810,8 @@ BLI_freelistN(image_free_queue); /* vbo buffers */ - GPU_buffer_pool_free_unused(0); + /* it's probably not necessary to free all buffers every frame */ + /* GPU_buffer_pool_free_unused(0); */ BLI_unlock_thread(LOCK_OPENGL); } ___ Bf-blender-cvs mailing list bf-blender-...@blender.org http://lists.blender.org/mailman/listinfo/bf-blender-cvs ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Have you seen this?? How to improve Blender
Real nice! I see that all the links are already made active, there is no problem with any of the other pages; they merge very well with this page. Someone should shift this to the homepage quickly! ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Text rendering
Here's a modified patch: http://www.pasteall.org/17139/diff The uneven font sizes look quite bad to me, they seem to be just a horizontally stretched version of font size - 1. On Fri, Nov 26, 2010 at 10:18 AM, Michael Fox mfoxd...@gmail.com wrote: Hi all quick question is there anyway of reinitialising the UI font's system during runtime. i have been working on making text AA an optional and made it in such a way that other options should be easy to add, however i have run into the last hurdle, the option requires the user to save the default then restart blender, this is not ideal, it should update as soon as the option is changed. the notifier NC_SCREEN is not High enough since font drawing is so deeply rooted and its not handled in NC_WINDOW and NC_WM. i would like to make a new notifier for this but there is really no functions open to reinitialise fonts. If any one can help please do what i have so far http://www.pasteall.org/17136/diff ___ 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] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [33308] branches/particles-2010/source/ blender: Added a simple curve node for customizable mapping.
Hi! it seems there are files missing? (SIM_curve.c) Greetz Philipp btw.: still cant figure out how to actually use the nodetree (even though I read your blog...), is there any example blends that demonstrate very basic usage? the ones you posted on your blog still crash here... Thanx for all your work! ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [33308] branches/particles-2010/source/ blender: Added a simple curve node for customizable mapping.
Hi! it seems there are files missing? (SIM_curve.c) Greetz Philipp btw.: still cant figure out how to actually use the nodetree (even though I read your blog...), is there any example blends that demonstrate very basic usage? the ones you posted on your blog still crash here... Thanx for all your work! ___ 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 [33308] branches/particles-2010/source/ blender: Added a simple curve node for customizable mapping.
Sorry, forgot to add it to SVN. This seems to have worked automatically from within QtCreator until recently, i'm just not used to adding them manually yet ;) About broken files: from time to time i make changes that break older files, and i'm just too lazy to make a do_versions for these little changes every time. As soon as a stable version can be declared the files created with that version should be kept compatible if possible. I will try to setup a nice new demo file and post it on the blog (thinking about making some kind of solar system animation, that can use many of the new features, such as group nodes and rotations). On Fri, Nov 26, 2010 at 2:53 PM, Philipp Oeser philippoe...@web.de wrote: Hi! it seems there are files missing? (SIM_curve.c) Greetz Philipp btw.: still cant figure out how to actually use the nodetree (even though I read your blog...), is there any example blends that demonstrate very basic usage? the ones you posted on your blog still crash here... Thanx for all your work! ___ 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 [33308] branches/particles-2010/source/ blender: Added a simple curve node for customizable mapping.
As long as the files are explicitly added to the CMakeLists.txt it will work, I made this change r32661. Without this we get a different problem where svn can add a file and CMake not register this unless its manually reconfigured. see http://www.cmake.org/pipermail/cmake/2008-December/025694.html On Fri, Nov 26, 2010 at 2:09 PM, Lukas Tönne lukas.toe...@googlemail.com wrote: Sorry, forgot to add it to SVN. This seems to have worked automatically from within QtCreator until recently, i'm just not used to adding them manually yet ;) About broken files: from time to time i make changes that break older files, and i'm just too lazy to make a do_versions for these little changes every time. As soon as a stable version can be declared the files created with that version should be kept compatible if possible. I will try to setup a nice new demo file and post it on the blog (thinking about making some kind of solar system animation, that can use many of the new features, such as group nodes and rotations). On Fri, Nov 26, 2010 at 2:53 PM, Philipp Oeser philippoe...@web.de wrote: Hi! it seems there are files missing? (SIM_curve.c) Greetz Philipp btw.: still cant figure out how to actually use the nodetree (even though I read your blog...), is there any example blends that demonstrate very basic usage? the ones you posted on your blog still crash here... Thanx for all your work! ___ 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 -- - Campbell ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] A practical proposal for the task of re-licensing Blender
My 2 cents on the matter is that closed source extensions to blender, in order to be useful, have to be missing from the free core of blender. That means that people who write commercial extensions may end up trying to influence the development of blender somehow(financially being the obvious way). This is a situation I wouldn't want to see arising. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] RNA property updates vs anim sys
Hi Matt, On Fri, Nov 26, 2010 at 12:28 AM, Matt Ebb m...@mke3.net wrote: On Thu, Nov 25, 2010 at 4:10 AM, Campbell Barton ideasma...@gmail.com wrote: On Wed, Nov 24, 2010 at 5:08 AM, Matt Ebb m...@mke3.net wrote: One possible solution is to queue unique update functions for each update, per ID. A function pointer GHash a check/w previous comparison should make collecting unique functions quite fast. Then these can run at the end, per ID. Well if this is necessary, it would be great to see. I suspect the reason this hasn't caused more problems elsewhere is that the depgraph kind of overlaps with this behaviour and probably masks the effect for a lot of blender data (i.e. scene objects automatically getting updated via depgraph, regardless of update functions). Presumably this doesn't extend fully to texture data. Anyway, I can try to work around this for now by making a whole bunch of abusive property set functions to do what should really be done by update functions but it's something that really should be fixed. If the purpose of RNA is to provide a unified, consistent interface to UI, python, animation system, then it's quite a problem that changing values via UI or python does the right thing, but via the animation system it decides to just not run the code that it's been told to. I'm looking into a way to make DAG_id_flush_update faster, that's probably the main culprit. Objects are slow because it actually flushes the flags each time, and materials/textures because it also loops over other data to free previews/glsl. My plan is add a generic recalc flag to ID, and only do the actual flushing delayed, as part of other updates in scene_update_tagged. Brecht. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Planet texture patch
Hey everyone,
here is a windows build with the planet patch:
http://blender.dingto.de/trunk_33341_with_planet.7z
Thomas
Am 25.11.2010 19:02, schrieb ra...@info.upr.edu.cu:
Hi all :)
well, I was expecting the GPU gems procedural parts before releasing the
patch in order to add others if needed but it didn't arrived.
some use advice:
at small scales (i.e the default textures values) it is a curl like
texture but at larger scales (size 1.0) and with 6 octaves in hard/soft
mode then it show the true planet procedural texture goodness :)
Anyway, here's the patch, is very easy and don't disrup any existent
Blender code so is pretty safe:
http://www.pasteall.org/17124/diff
//-
Index: release/scripts/ui/properties_texture.py
===
--- release/scripts/ui/properties_texture.py (revision 32153)
+++ release/scripts/ui/properties_texture.py (working copy)
@@ -444,8 +444,33 @@
col = split.column()
col.prop(tex, nabla, text=Nabla)
+
+class TEXTURE_PT_planet(TextureTypePanel, bpy.types.Panel):
+bl_label = Planet
+tex_type = 'PLANET'
+COMPAT_ENGINES = {'BLENDER_RENDER', 'BLENDER_GAME'}
+def draw(self, context):
+layout = self.layout
+tex = context.texture
+
+layout.prop(tex, planet_type, expand=True)
+layout.label(text=Noise:)
+layout.prop(tex, noise_type, text=Type, expand=True)
+layout.prop(tex, noise_basis, text=Basis)
+
+split = layout.split()
+
+col = split.column()
+col.prop(tex, noise_scale, text=Size)
+col.prop(tex, noise_depth, text=Depth)
+
+col = split.column()
+col.prop(tex, nabla, text=Nabla)
+
+
+
class TEXTURE_PT_wood(TextureTypePanel, bpy.types.Panel):
bl_label = Wood
tex_type = 'WOOD'
Index: source/blender/blenkernel/intern/node.c
===
--- source/blender/blenkernel/intern/node.c (revision 32153)
+++ source/blender/blenkernel/intern/node.c (working copy)
@@ -3185,6 +3185,7 @@
nodeRegisterType(ntypelist,tex_node_proc_noise);
nodeRegisterType(ntypelist,tex_node_proc_stucci);
nodeRegisterType(ntypelist,tex_node_proc_distnoise);
+ nodeRegisterType(ntypelist,tex_node_proc_planet);
}
static void remove_dynamic_typeinfos(ListBase *list)
Index: source/blender/editors/space_node/drawnode.c
===
--- source/blender/editors/space_node/drawnode.c (revision 32153)
+++ source/blender/editors/space_node/drawnode.c (working copy)
@@ -1202,6 +1202,15 @@
uiItemR(row,tex_ptr, noise_type, UI_ITEM_R_EXPAND,
NULL, 0);
uiItemR(col,tex_ptr, noise_depth, UI_ITEM_R_EXPAND,
Depth, 0);
break;
+
+ case TEX_PLANET:
+ uiItemR(col,tex_ptr, noise_basis, 0, , 0);
+ row= uiLayoutRow(col, 0);
+ uiItemR(row,tex_ptr, stype, UI_ITEM_R_EXPAND, NULL,
0);
+ row= uiLayoutRow(col, 0);
+ uiItemR(row,tex_ptr, noise_type, UI_ITEM_R_EXPAND,
NULL, 0);
+ uiItemR(col,tex_ptr, noise_depth, UI_ITEM_R_EXPAND,
Depth, 0);
+ break;
case TEX_DISTNOISE:
uiItemR(col,tex_ptr, noise_basis, 0, , 0);
Index: source/blender/makesdna/DNA_texture_types.h
===
--- source/blender/makesdna/DNA_texture_types.h (revision 32153)
+++ source/blender/makesdna/DNA_texture_types.h (working copy)
@@ -294,6 +294,7 @@
#define TEX_DISTNOISE 13
#define TEX_POINTDENSITY14
#define TEX_VOXELDATA 15
+#define TEX_PLANET 16
/* musgrave stype */
#define TEX_MFRACTAL0
Index: source/blender/makesrna/intern/rna_texture.c
===
--- source/blender/makesrna/intern/rna_texture.c (revision 32153)
+++ source/blender/makesrna/intern/rna_texture.c (working copy)
@@ -66,6 +66,7 @@
{TEX_VORONOI, VORONOI, ICON_TEXTURE, Voronoi, },
{TEX_VOXELDATA, VOXEL_DATA, ICON_TEXTURE, Voxel Data, },
{TEX_WOOD, WOOD, ICON_TEXTURE, Wood, },
+ {TEX_PLANET, PLANET, ICON_TEXTURE, Planet, },
{0, NULL, 0, NULL, NULL}};
#ifdef RNA_RUNTIME
@@ -119,6 +120,8 @@
returnRNA_VoxelDataTexture;
case TEX_WOOD:
returnRNA_WoodTexture;
+ case TEX_PLANET:
+ returnRNA_PlanetTexture;
default:
returnRNA_Texture;
}
@@ -706,6 +709,60 @@
RNA_def_property_update(prop, 0,
Re: [Bf-committers] Have you seen this?? How to improve Blender
Hi, Don't worry, I won't allow such cliche language on blender.org. :) The proposal has good aspects too. For an improved blender.org I'll setup a project later, with forum where people can leave comments. Not a real topic for further discussion here either. For everyone as reminder: this mailing list is about blender software development progress, and making stable releases. It is firstmost meant for people who want to be involved with this, by contributing or by becoming a contributor. -Ton- Ton Roosendaal Blender Foundation t...@blender.orgwww.blender.org Blender Institute Entrepotdok 57A 1018AD Amsterdam The Netherlands On 26 Nov, 2010, at 13:59, Nathaniel Garbutt wrote: To be quite frank, I personally am not into the tone of this design at all. It comes across as a pushy sales pitch, somewhat like those people that pretend to be your best friend while trying to sell you a mobile phone or something. -Text like: Blender is an open-source 3d animation software that allows anyone to create hollywood-style visuals from their PC is disingenuous, very clichéd and reminds me instantly of 3dmagix. -The list down the left hand sideis ok but the ticks next to them cheapen it in my opinion. -The large pictures at the top look nice but the huge quotes I think are tacky. My critique is mostly to do with the message being conveyed as the visual style is not a huge deviation and has elements that look quite nice. The choice of language is poor, comes across as cheap, slightly desperate and lacks dignity. This is just my opinion so please take it as that. Nathaniel From: Leo Sutic leo.su...@gmail.com To: bf-blender developers bf-committers@blender.org Sent: Fri, 26 November, 2010 9:46:26 PM Subject: Re: [Bf-committers] Have you seen this?? How to improve Blender Now that is slick. /LS On 2010-11-26 11:13, Steren wrote: I saw a link posted by Andrew showing a first online prorotype of the home page : http://69.164.205.151/blender/ On Fri, Nov 26, 2010 at 5:22 AM, Prashant Sohani prashant.soh...@gmail.comwrote: Well.. I am reviving this old thread.. The points raised in the presentation were very valid; I think it's high time we act on some of them. Has anybody a ready new home page for blender.org? If not, I volunteer to redesign the homepage of Blender and any other parts that may be wanting a complete overhaul. I have reasonably good skills in web development. (I am just done with an exceptionally heavy semester, and have a month's holiday ahead of me.) And of course, anybody else willing to volunteer, is welcome as well :) I'll create my own version on my website, and I'll post the link(s) in a new thread.. people may comment on it etc. In the meanwhile, let's start brainstorming about what we can do about the other points raised in the same presentation. ___ 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] Planet texture patch
here is a Linux build with the Planet texture, 64-bit nocona arch., built using Ubuntu 10.10, r33343 http://rowdyrabbit.com/blender/BlenderWithPlanetTexLinux64bitNocona.tar.gz On 11/26/2010 09:49 AM, Thomas Dinges wrote: Hey everyone, here is a windows build with the planet patch: http://blender.dingto.de/trunk_33341_with_planet.7z Thomas Am 25.11.2010 19:02, schrieb ra...@info.upr.edu.cu: Hi all :) well, I was expecting the GPU gems procedural parts before releasing the patch in order to add others if needed but it didn't arrived. some use advice: at small scales (i.e the default textures values) it is a curl like texture but at larger scales (size 1.0) and with 6 octaves in hard/soft mode then it show the true planet procedural texture goodness :) Anyway, here's the patch, is very easy and don't disrup any existent Blender code so is pretty safe: http://www.pasteall.org/17124/diff ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Have you seen this?? How to improve Blender
@Ton: i can't help feel that there is so much more to improving software than just development progress and making stable releases, if that is what this mailing list is about. Of course, all those other aspects better not be mixed into the chief task of coding progress, so in that respect I agree that this topic does not really belong here. But then, we still need to discuss such topics. What can be done about this? ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Text rendering
Actually, now that I've thought about it a little it would be even nicer if it didn't reload currently loaded fonts at all but instead took the current UI font and loaded it into a new texture slot with AA turned off (if that's even possible). That way people can (almost) always depend on texture_slot[0] being bfont with all the default settings when they want to use bgl/blf to draw some pixel-perfect stuff on the display. Dan ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Per tile subdivission wil get into trunk?
Hi all Probably I have missed something but one of the coolest feature of the Sintel dev side was the per tile subdivission feature: - In which state is? - It is planned to go to Trunk? thanks in advance Farsthary ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] A practical proposal for the task of re-licensing Blender
At the company I work for, we are doing a project that requires customisation of Blender. Traditionally, the client has been heavily against the idea of free software. But Blender is so good, and the benefits of being able to modify it are so great that it can't be ignored. The client is even considering giving the changes back to the community. I consider this to be a big win for free software, because even if they choose not to this time, they are now aware of the potential benefits. If companies have no choice but to release their extensions as free software, then that's fantastic. Encouraging it is exactly what the GPL is supposed to do. My apologies for continuing this thread - I just thought another industry perspective would be useful. Cheers, Alex ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
