Re: [Bf-committers] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [41508] trunk/blender/source/blender/ editors/interface/interface_handlers.c: Enabled ndof devices for controlling colour wheel an
Great news, thanks! Very nice to hear you're still working on it. My last post was not meant as a complaint, so I hope you didn't take it as such. Do you keep a wiki page or a blog or something, where progress could be followed? I guess concerns start growing when we don't know what's going on. Cheers, -mats Mats Holmberg, ArtFlow 3D-Animation / 3D-Graphics / Airbrush Art & Supplies mobile +358 (0) 40 1920382 email mats.holmb...@artflow.fi www.artflow.fi www.maalinetti.com On 5.11.2011, at 3.26, Mike Erwin wrote: > Here's the latest news -- I hope this eases some of your concerns. > > Toward the end of the push for 2.59/siggraph, I was offered (and accepted) a > great job far away in the frozen northland. 3D mouse progress on my end > approached zero during the move and ramping up at work, but at no point did I > consider this project "dead in its tracks". Now operating in > otherwise-employed-volunteer mode -- nights and weekends -- I've been > prototyping against the 2.60 release. I have stated on this list plans to > have the major NDOF issues fixed for 2.61, and still think this is doable. > Very much aware of the pile of suggestions, patches, reviews, bug reports, > etc. about where 2.59 did and did not work for people, I'm glad to finally be > able to get back in there and make it better. > > I'll be focusing on the 3D view for now. It's great to see folks adding > support in other areas too! > > Mike Erwin > musician, naturalist, pixel pusher, hacker extraordinaire > > > On Fri, Nov 4, 2011 at 5:34 PM, Mats Holmberg wrote: > Hi, > > Do you know anything about the state of the integration? Is it meant to be > continued at some point, or is it being worked on at the moment? I haven't > really heard any news on this. > > It seems as if development stopped dead in it's tracks. Quite a few features > are still missing, which means that at least my 3d-mouse sits unused on my > desk (except for occasional Lightwave use). Compared to other programs I > believe that the most important missing features still are panning, the > ability to control objects and even scrubbing the timeline. > > It's a bit of a shame, because 3Dconnexion really wanted to get the best > integration in Blender. And good integration would help users of other > software adopt Blender in their workflow too. > > -mats > ___ 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 [41508] trunk/blender/source/blender/ editors/interface/interface_handlers.c: Enabled ndof devices for controlling colour wheel an
Hi,
Do you know anything about the state of the integration? Is it meant to be
continued at some point, or is it being worked on at the moment? I haven't
really heard any news on this.
It seems as if development stopped dead in it's tracks. Quite a few features
are still missing, which means that at least my 3d-mouse sits unused on my desk
(except for occasional Lightwave use). Compared to other programs I believe
that the most important missing features still are panning, the ability to
control objects and even scrubbing the timeline.
It's a bit of a shame, because 3Dconnexion really wanted to get the best
integration in Blender. And good integration would help users of other software
adopt Blender in their workflow too.
-mats
On Nov 4, 2011, at 11:16 PM, Matt Ebb wrote:
> Hi,
>
> As far as I'm aware there's currently no way to customise built in UI
> handlers like this one. For this one in particular, I really don't think
> it's a problem, it's very simple. But I'm guessing this response comes from
> frustration with the ndof 3D View navigation, and if so I agree with you, I
> don't find it usable at the moment. On a quick glance that's an operator so
> it might be possible to do that with a modal keymap. I'll be away for a
> little while but I can possibly take a look at that if I have free time
> when I return.
>
> cheers
>
> Matt
>
>
> On Fri, Nov 4, 2011 at 2:38 PM, Daniel Salazar - 3Developer.com <
> zan...@gmail.com> wrote:
>
>> It's not a matter of sensitivity, what happens is everyone has a different
>> way to use the device: tilt vs pan vs roll vs inverted axis. Currently
>> everyone just adds what ever they feel it's best but why can't this be
>> configurable like keymaps are?
>>
>> Daniel Salazar
>> 3Developer.com
>>
>>
>> On Thu, Nov 3, 2011 at 9:30 PM, Campbell Barton >> wrote:
>>
>>> Do you mean configure sensitivity or disable options like this?
>>>
>>> On Fri, Nov 4, 2011 at 1:41 PM, Daniel Salazar - 3Developer.com
>>> wrote:
Gah all this seriously needs to be configurable, what a mess if
>> everyone
just ads their own preferences
Daniel Salazar
3Developer.com
On Thu, Nov 3, 2011 at 8:31 PM, Matt Ebb wrote:
> Revision: 41508
>
>
>>>
>> http://projects.blender.org/scm/viewvc.php?view=rev&root=bf-blender&revision=41508
> Author: broken
> Date: 2011-11-04 02:31:00 + (Fri, 04 Nov 2011)
> Log Message:
> ---
> Enabled ndof devices for controlling colour wheel and cube UI controls
> (eg. colour pickers). Tilting the ndof device up and down and rolling
>> it
> left and
> right will move the 'colour cursor' in screen x and y, and twisting
>> the
> ndof device
> will rotate the cursor around the colour wheel (hue). Now you can turn
>>> off
> the
> lights and pretend you have a fancy DI deck!
>
> Modified Paths:
> --
> trunk/blender/source/blender/editors/interface/interface_handlers.c
>
> Modified:
> trunk/blender/source/blender/editors/interface/interface_handlers.c
> ===
> ---
>> trunk/blender/source/blender/editors/interface/interface_handlers.c
> 2011-11-04 01:15:04 UTC (rev 41507)
> +++
>> trunk/blender/source/blender/editors/interface/interface_handlers.c
> 2011-11-04 02:31:00 UTC (rev 41508)
> @@ -3216,6 +3216,63 @@
> return changed;
> }
>
> +static void ui_ndofedit_but_HSVCUBE(uiBut *but, uiHandleButtonData
>>> *data,
> wmNDOFMotionData *ndof, int shift)
> +{
> + float *hsv= ui_block_hsv_get(but->block);
> + float rgb[3];
> + float sensitivity = (shift?0.15:0.3) * ndof->dt;
> +
> + int color_profile = but->block->color_profile;
> +
> + if (but->rnaprop) {
> + if (RNA_property_subtype(but->rnaprop) ==
>>> PROP_COLOR_GAMMA)
> + color_profile = BLI_PR_NONE;
> + }
> +
> + ui_get_but_vectorf(but, rgb);
> + rgb_to_hsv_compat(rgb[0], rgb[1], rgb[2], hsv, hsv+1, hsv+2);
> +
> + switch((int)but->a1) {
> + case UI_GRAD_SV:
> + hsv[2] += ndof->ry * sensitivity;
> + hsv[1] += ndof->rx * sensitivity;
> + break;
> + case UI_GRAD_HV:
> + hsv[0] += ndof->ry * sensitivity;
> + hsv[2] += ndof->rx * sensitivity;
> + break;
> + case UI_GRAD_HS:
> + hsv[0] += ndof->ry * sensitivity;
> + hsv[1] += ndof->rx * sensitivity;
> + break;
> + case UI_GRAD_H:
> + hsv[0] += ndof->ry * sensitivity;
> + break;
Re: [Bf-committers] Multitouch Trackpads on OS X
Great, thanks! Already what you did (reducing zoom sensitivity to half) makes everything _much_ better. -mats On Oct 31, 2011, at 2:16 PM, Jens Verwiebe wrote: > Atm iám working on a solution. > > Zoomgesture is a bit too sensible, right. > > + i must find a way to distinguish magic mouse pan and trackpad pan due 1 > finger moving on mm trackpadarea > is doing pan ( same as 2 finger pan on trackpad ). > > In trunk for testing atm: all gestures are handled as expected also when > having a trackpad > on non-books ( magic trackpad @ MacPro for example ). > > Need a bit time for this for ám working also on utf8 fix. > > Jens > > > > > Am 31.10.2011 um 12:43 schrieb François T.: > >> in addition to that, in many space as in compositor, the trackpad does not >> zoom to the mouse position (when this is turn on in pref). which is a bit >> annoying to be honest. and the sensitivity is really high (again mostly in >> compositor since its what I use, but maybe in other places) >> After all its been a while since I re-build so maybe this as been fixed >> >> 2011/10/31 Mats Holmberg >> >>> I would like to see this improved a bit too. As it is now, it's really >>> difficult to pan without accidentally zooming (or the other way around). >>> >>> But if you'd use three finger pan, would then the rotation be OPTION + >>> three fingers? That suddenly feels a bit awkward, but maybe it could work. >>> >>> -mats >>> >>> Mats Holmberg, ArtFlow >>> 3D-Animation / 3D-Graphics / Airbrush Art & Supplies >>> >>> mobile +358 (0) 40 1920382 >>> email mats.holmb...@artflow.fi >>> >>> www.artflow.fi >>> www.maalinetti.com >>> >>> On 31.10.2011, at 2.03, Jonathan Williamson >>> wrote: >>> >>>> Hi there, in particular Jens (I believe you are the main OS X guy?), >>>> >>>> In order to improve the usage of multitouch trackpads on newer MacBooks >>> would it be possible to modify the current behavior to be: >>>> Two fingers to zoom, would be consistent with scrolling in other apps >>>> Three fingers to pan >>>> >>>> Currently the inertia scroll for zooming and pinch to zoom are more >>> difficult to use and cause lots of unintended navigation. >>>> >>>> >>>> Thoughts? >>>> >>>> -- >>>> Jonathan Williamson >>>> Sent with Sparrow (http://www.sparrowmailapp.com/?sig) >>>> ___ >>>> 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 >>> >> >> >> >> -- >> >> François Tarlier >> www.francois-tarlier.com >> www.linkedin.com/in/francoistarlier >> ___ >> Bf-committers mailing list >> Bf-committers@blender.org >> http://lists.blender.org/mailman/listinfo/bf-committers > > _ > > Jens Verwiebe > Allerskehre 44 - 22309 Hamburg > > Tel.: +49 40 68 78 50 > mobil: +49 172 400 49 07 > mailto: i...@jensverwiebe.de > web: http://www.jensverwiebe.de > _ > > ___ > 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] Multitouch Trackpads on OS X
I would like to see this improved a bit too. As it is now, it's really difficult to pan without accidentally zooming (or the other way around). But if you'd use three finger pan, would then the rotation be OPTION + three fingers? That suddenly feels a bit awkward, but maybe it could work. -mats Mats Holmberg, ArtFlow 3D-Animation / 3D-Graphics / Airbrush Art & Supplies mobile +358 (0) 40 1920382 email mats.holmb...@artflow.fi www.artflow.fi www.maalinetti.com On 31.10.2011, at 2.03, Jonathan Williamson wrote: > Hi there, in particular Jens (I believe you are the main OS X guy?), > > In order to improve the usage of multitouch trackpads on newer MacBooks would > it be possible to modify the current behavior to be: > Two fingers to zoom, would be consistent with scrolling in other apps > Three fingers to pan > > Currently the inertia scroll for zooming and pinch to zoom are more difficult > to use and cause lots of unintended navigation. > > > Thoughts? > > -- > Jonathan Williamson > Sent with Sparrow (http://www.sparrowmailapp.com/?sig) > ___ > 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 [41345] trunk/blender/source/blender: Fix: OpenGL renders on graphics cards which do not support non-power-of-two
Thanks Brecht!
-mats
On Oct 28, 2011, at 7:57 PM, Brecht Van Lommel wrote:
> Revision: 41345
>
> http://projects.blender.org/scm/viewvc.php?view=rev&root=bf-blender&revision=41345
> Author: blendix
> Date: 2011-10-28 16:57:06 + (Fri, 28 Oct 2011)
> Log Message:
> ---
> Fix: OpenGL renders on graphics cards which do not support non-power-of-two
> textures were stretched and the wrong size.
>
> Modified Paths:
> --
>trunk/blender/source/blender/editors/render/render_opengl.c
>trunk/blender/source/blender/editors/space_view3d/view3d_draw.c
>trunk/blender/source/blender/gpu/GPU_extensions.h
>trunk/blender/source/blender/gpu/intern/gpu_extensions.c
>trunk/blender/source/blender/gpu/intern/gpu_material.c
>
> Modified: trunk/blender/source/blender/editors/render/render_opengl.c
> ===
> --- trunk/blender/source/blender/editors/render/render_opengl.c
> 2011-10-28 16:13:07 UTC (rev 41344)
> +++ trunk/blender/source/blender/editors/render/render_opengl.c
> 2011-10-28 16:57:06 UTC (rev 41345)
> @@ -154,7 +154,7 @@
>
> if((scene->r.mode & R_OSA) == 0) {
> ED_view3d_draw_offscreen(scene, v3d, ar, sizex, sizey,
> NULL, winmat);
> - glReadPixels(0, 0, sizex, sizey, GL_RGBA, GL_FLOAT,
> rr->rectf);
> + GPU_offscreen_read_pixels(oglrender->ofs, GL_FLOAT,
> rr->rectf);
> }
> else {
> /* simple accumulation, less hassle then FSAA FBO's */
> @@ -167,7 +167,7 @@
>
> /* first sample buffer, also initializes
> 'rv3d->persmat' */
> ED_view3d_draw_offscreen(scene, v3d, ar, sizex, sizey,
> NULL, winmat);
> - glReadPixels(0, 0, sizex, sizey, GL_RGBA, GL_FLOAT,
> accum_buffer);
> + GPU_offscreen_read_pixels(oglrender->ofs, GL_FLOAT,
> accum_buffer);
>
> /* skip the first sample */
> for(j=1; j < SAMPLES; j++) {
> @@ -175,7 +175,7 @@
> window_translate_m4(winmat_jitter,
> rv3d->persmat, jit_ofs[j][0] / sizex, jit_ofs[j][1] / sizey);
>
> ED_view3d_draw_offscreen(scene, v3d, ar, sizex,
> sizey, NULL, winmat_jitter);
> - glReadPixels(0, 0, sizex, sizey, GL_RGBA,
> GL_FLOAT, accum_tmp);
> + GPU_offscreen_read_pixels(oglrender->ofs,
> GL_FLOAT, accum_tmp);
> add_vn_vn(accum_buffer, accum_tmp,
> sizex*sizey*sizeof(float));
> }
>
> @@ -278,7 +278,7 @@
> sizey= (scene->r.size*scene->r.ysch)/100;
>
> /* corrects render size with actual size, not every card supports
> non-power-of-two dimensions */
> - ofs= GPU_offscreen_create(&sizex, &sizey, err_out);
> + ofs= GPU_offscreen_create(sizex, sizey, err_out);
>
> if(!ofs) {
> BKE_reportf(op->reports, RPT_ERROR, "Failed to create OpenGL
> offscreen buffer, %s", err_out);
>
> Modified: trunk/blender/source/blender/editors/space_view3d/view3d_draw.c
> ===
> --- trunk/blender/source/blender/editors/space_view3d/view3d_draw.c
> 2011-10-28 16:13:07 UTC (rev 41344)
> +++ trunk/blender/source/blender/editors/space_view3d/view3d_draw.c
> 2011-10-28 16:57:06 UTC (rev 41345)
> @@ -2379,7 +2379,7 @@
> glPushAttrib(GL_LIGHTING_BIT);
>
> /* bind */
> - ofs= GPU_offscreen_create(&sizex, &sizey, err_out);
> + ofs= GPU_offscreen_create(sizex, sizey, err_out);
> if(ofs == NULL)
> return NULL;
>
> @@ -2403,9 +2403,9 @@
> ibuf= IMB_allocImBuf(sizex, sizey, 32, flag);
>
> if(ibuf->rect_float)
> - glReadPixels(0, 0, sizex, sizey, GL_RGBA, GL_FLOAT,
> ibuf->rect_float);
> + GPU_offscreen_read_pixels(ofs, GL_FLOAT, ibuf->rect_float);
> else if(ibuf->rect)
> - glReadPixels(0, 0, sizex, sizey, GL_RGBA, GL_UNSIGNED_BYTE,
> ibuf->rect);
> + GPU_offscreen_read_pixels(ofs, GL_UNSIGNED_BYTE, ibuf->rect);
>
> //if((scene->r.stamp & R_STAMP_ALL) && (scene->r.stamp & R_STAMP_DRAW))
> // BKE_stamp_buf(scene, NULL, rr->rectf, rr->rectx, rr->recty, 4);
>
> Modified: trunk/blender/source/blender/gpu/GPU_extensions.h
> ===
> --- trunk/blender/source/blender/gpu/GPU_extensions.h 2011-10-28 16:13:07 UTC
> (rev 41344)
> +++ trunk/blender/source/blender/gpu/GPU_extensions.h 2011-10-28 16:57:06 UTC
> (rev 41345)
> @@ -136,7 +136,7 @@
> GPUFrameBuffer *GPU_framebuffer_create(void);
> int GPU_framebuffer_texture_attach(GPUFrameBuffer *fb, GPUTexture *tex, char
> err_out[256]);
> void GPU_framebuffer_texture_detach(GPUFrameBuffer *fb, GPUTexture *tex);
> -void
Re: [Bf-committers] 2.60 OSX
Hi, It's dodgy still. It's best to try different setting and see what works best (or least bad, that is). On my Mac Pro, at best, Blender smoke sim utilizes 6-7 % of my cpu. That's with 16 threads (8 real, 8 virtual cores). Fluids are the same. I don't see any change, no matter what I put in the set_simulation_threads app. In fact, for some reason even setting the environment variable OMP_NUM_THREADS doesn't seem to work anymore. I still use my dual core Macbook Pro for all sims, it's about ten times faster than my 8-core desktop machine! Cheers, -mats On Oct 20, 2011, at 12:06 AM, Tobias Kummer wrote: > Hey there! > > What am I supposed to put in the set_simulation_threads.app? Number of > real cores? Or including Hyperthreading? > > Cheers & congrats for the release, > > Tobi > ___ > 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] OpenMP on osx
Oh yes! I can confirm. It has been a problem for a long time, I first noticed it about six months ago when I got a new machine. It's been discussed over at IRC, but no resolutions yet. My Mac Pro cannot really be used for simulations at all, my MacBook Pro is a lot faster. This is a bit weird since my pro is an 8-core machine, while the laptop is dual core. I tried compile using newer gcc versions through macports, but always ran into (for me) unsolvable errors. -mats On 16.8.2011, at 13.54, Tobias Kummer wrote: > Hey there! > > I just realized that when using an OpenMP enabled build on osx (cmake), > all simulations and baking run terribly slow. When I compile the same > revision with OpenMP disabled, it uses one core at 100% and is MUCH > faster. Can anyone confirm this? Are there known problems with OpenMP on > OSX? > > Greets, > Tobi > ___ > 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] Linking error with OS X Lion
Hi, I had the same problem, but my solution was to build against SDK 10.6, which I had installed for snow leopard. I just modified my user-config.py accordingly. Everything seems to work ok. -mats Mats Holmberg, ArtFlow 3D-Animation / 3D-Graphics / Airbrush Art & Supplies mobile +358 (0) 40 1920382 email mats.holmb...@artflow.fi www.artflow.fi www.maalinetti.com On 25.7.2011, at 22.08, Markus Kasten wrote: > Hello everyone, > > when building GSoC branches (tested Tomato and Salad) under Lion, I get the > error > > ld: library not found for -lSystemStubs > collect2: ld returned 1 exit status > > when linking blender. when I remove 'SystemStubs' from line 300 in > darwin-config.py it links correctly without errors (and the build seems to > work). > > Markus > ___ > 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] Is alpha within Blender totally broken?
You are on the right tracks, Troy. The alpha issue is something we've been pondering about at Studio Lumikuu also. If you composite within Blender there really are no issues, but, in my case, using After Effects gives very weird results. I've always used premultiplied png -files before, as nothing else ever seemed to work, but from feedback I understood that this is plain wrong (the results were fine though, which tells me that Blender does it wrong). Anyways, I'm not able to look into this at the moment and produce any examples - I could check and report my results tomorrow. But just to let you know, I agree completely that there is something _seriously_ wrong about how Blender handles alpha channels. Cheers, -mats On 17.7.2011, at 6.06, Reuben Martin wrote: > On Saturday, July 16, 2011 02:37:57 PM Troy Sobotka wrote: >> So far, I've been experimenting with several files and uptake tools >> using Blender in conjunction with Nuke. I have yet to be able to find >> a pattern that delivers proper alpha channels.Perhaps someone here can >> shed some light on the matter. > > I can't speak for Nuke, but if blender has a bug concerning alpha channels > when rendering, then it also has the same bug in the compositer, because I've > never had issues keying anything. > > The first two images look like what happens when trying to key a > pre-multiplied image with a white background that isn't properly removing the > matte. The second two look like trying to > key with the matte being removed, but not useing linear color space blending > in the compositing. But I don't know what your actual settings are. > > Straight-keyed Alpha, CM on, rendered to Half-Exr, Composited with CM on. (in > blender) http://img692.imageshack.us/img692/779/compositescreencap.png > > -Reuben > ___ > 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] Camera view navigation rant
And if this would work for the camera, then it should also work for anything
else (lamps mainly). The script didn't work for me on osx - the view is not
locked to the camera view and trackballing around loses the camera lock
alltogether =)
Cheers,
-mats
On 27.4.2011, at 1.39, Daniel Salazar - 3Developer.com wrote:
> @dfelinto(pto): nope, it would need to *stay* in camera view when panning
> and dollying around :)
>
> Daniel Salazar
> 3Developer.com
>
>
>
> On Tue, Apr 26, 2011 at 12:58 PM, Dalai Felinto wrote:
>>> Below you can find some code for (...) Lock camera to view.
>> Isn't this what Ctrl+Alt+Numpad0 do? (align camera to view -- which
>> even takes care of non-perspective views)
>>
>> On my understanding what people are ranting is for the lack of options
>> to move while "inside" the camera mode.
>>
>> --
>> Dalai
>>
>> 2011/4/26 bartius crouch :
Also a lock camera to view option would be great so we can just move
the camera like we move any other viewport
>>>
>>> Like Campbell said, that isn't very hard to do in python. Below you can find
>>> some code for it.
>>> Copy the text below into the text-editor, Run Script (alt+P), go to 3d-view,
>>> search (spacebar) for Lock camera to view.
>>>
>>>
>>>
>>> import bpy
>>> import mathutils
>>>
>>>
>>> class ModalOperator(bpy.types.Operator):
>>>'''Move camera along with the viewport'''
>>>bl_idname = "view3d.lock_camera"
>>>bl_label = "Lock camera to view"
>>>
>>>@classmethod
>>>def poll(cls, context):
>>>camera = context.scene.camera
>>>if not camera:
>>>return(False)
>>>return(camera.name in context.scene.objects)
>>>
>>>def modal(self, context, event):
>>>camera = context.scene.camera
>>>rv3d = context.space_data.region_3d
>>>
>>># rotation + location
>>>camera.matrix_world = rv3d.view_matrix.copy().inverted()
>>>
>>># override location to take view_distance into account
>>>rotation = rv3d.view_matrix.copy().to_3x3().inverted()
>>>z_normal = mathutils.Vector([0.0, 0.0, 1.0]) * rotation
>>>camera.location = rv3d.view_location + (rv3d.view_distance *
>>> z_normal)
>>>
>>># handle events
>>>if event.type in ['LEFTMOUSE', 'NUMPAD_ENTER', 'RET']:
>>>context.area.header_text_set()
>>>return {'FINISHED'}
>>>elif event.type == 'ESC':
>>>camera.matrix_world = self.camera_matrix
>>>context.area.header_text_set()
>>>return {'CANCELLED'}
>>>
>>>return {'PASS_THROUGH'}
>>>
>>>def invoke(self, context, event):
>>>context.window_manager.modal_handler_add(self)
>>>self.camera_matrix = context.scene.camera.matrix_world.copy()
>>>context.space_data.region_3d.view_perspective = 'PERSP'
>>>context.area.header_text_set("ESC to cancel, ENTER or LMB to
>>> confirm")
>>>return {'RUNNING_MODAL'}
>>>
>>>
>>> def register():
>>>bpy.utils.register_class(ModalOperator)
>>>
>>>
>>> def unregister():
>>>bpy.utils.unregister_class(ModalOperator)
>>>
>>>
>>> if __name__ == "__main__":
>>>register()
>> ___
>> 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] Updated Camera patch
And another huge +1 here. I do some visualizations for print, the scenes are modeled and setup in blender, but rendered in other programs. Matching the camera _exactly_ is a big problem. -mats On 12.3.2011, at 4.12, Troy Sobotka wrote: > On Fri, Mar 11, 2011 at 8:19 AM, Ejner Fergo wrote: >> In any case I hope you will consider including this updated camera. > > Huge +1 here. > ___ > 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 Startup Time
Blender still has blazing fast startup (compared to any app). I'd be really happy keeping it that way, but I do agree that wether it takes three, four or five seconds seems quite irrelevant. Mats Holmberg, ArtFlow 3D-Animation / 3D-Graphics / Airbrush Art & Supplies mobile +358 (0) 40 1920382 email mats.holmb...@artflow.fi www.artflow.fi www.maalinetti.com On 25.2.2011, at 20.58, Toni Alatalo wrote: > On Feb 25, 2011, at 8:53 PM, Carsten Wartmann wrote: >> How often do I start Blender a day? If I am lucky ONE time. If not the >> next starts are warm starts. > > It is different for devs who need to restart constantly to see if got a bug > fixed etc :) > > But a good point anyway, even there 5secs is not a lot. > >> Carsten > > ~Toni > > ___ > 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] Fluid particles refactoring
On 19.2.2011, at 20.20, ra...@info.upr.edu.cu wrote: > Is on the way ;) This comment really made my day =D Thanks. -mats ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Blender 2.5x beta status
I'm a mac user, but have never like the .dmg approach. It is probably done with good intentions in mind, but makes a really simple thing (copying a directory) unnecessarily complicated. I'd rather see the most simple solution, accompanied by just as simple an explanation =) I came from Linux to Mac, but the beautiful backgrounds, arrows and symbolic links to the Applications folder didn't help me a bit. Just couldn't understand the install process... why? Because all the fancyness lead me away from what it actually is, i.e. copying a directory. -mats On 14.7.2010, at 8.42, Benjamin Tolputt wrote: > Mats Holmberg wrote: >> Sadly many people still think of "installation" as being something mythical, >> even a bit frightening, no matter what the platform is. If we can counter >> that, great. +1 for an uncomplicated .zip approach! >> > > And on some platforms for some applications it is (mythical and > frightening). However, Blender doesn't need to install DRM drivers, has > it's own copy of Python tucked neatly away inside, and is installed by a > simple drag & drop operation on the Mac (on the Windows as well, but > we're not talking about that here). > > In fact, a good majority of the DMG installations I've had for Mac OSX > involve a window showing the application icon, the Applications > directory icon, and an arrow showing you to drag the former onto the > latter. It is simply the way things are done now on Mac OSX :) > > And this from a guy who isn't terribly fond of Apple :) > > -- > Regards, > > Benjamin Tolputt > Analyst Programmer > > ___ > 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 2.5x beta status
Sadly many people still think of "installation" as being something mythical, even a bit frightening, no matter what the platform is. If we can counter that, great. +1 for an uncomplicated .zip approach! -mats On 14.7.2010, at 6.14, Mike Belanger wrote: > Have to agree with William and Benjamin. The mounting/unmounting disk-image > thing is probably from OSX's Unix background, not designed for people at > all. > > On Tue, Jul 13, 2010 at 8:43 PM, Benjamin Tolputt > wrote: > >> William Reynish wrote: >>> I think zip is much simpler to understand and manage for the user, it's >> also faster too (no need to mount, drag-to-apps, unmount). >>> >> >>> From a non-technical standpoint (my wife), installing from a zip is not >> an issue. Simply double click the zip in the downloads dir and drag to >> the Applications shortcut in the taskbar. She's done this so many times >> now it is second nature and she is not technically trained in any way, >> shape, or form. >> >> -- >> Regards, >> >> Benjamin Tolputt >> Analyst Programmer >> >> ___ >> Bf-committers mailing list >> Bf-committers@blender.org >> http://lists.blender.org/mailman/listinfo/bf-committers >> > > > > -- > www.watchmike.ca > ___ > 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] Proposal to Remove Features
Personally, I'm not against field rendering staying in Blender. If it's used, of course it should not be removed. I do understand what fields are used for, and what problems fields originally were meant to tackle. My point here is that in my case, I always render things in parts, move things around and scale my rendered output during the compositing phase. So it's then better to use progressive renders, as moving or scaling interlaced footage is impossible (without removing fields, which throws away half of the image resolution). Cheers, -mats On 9.7.2010, at 18.42, Roger Wickes wrote: > Fields provides motion blur and much smoother video than progressive at the > same > frame rate. 30i is effectively shown at 60hz, and the result is much smoother > motion than 30p, without Blender calculating a specific MBlur or vector > blurl; > turn on fields and it does an automatic "tween frame". > > > On the INPUT side, working with interlaced input in the comp, you have to > de-interlace to do any meaningful mask work etc. You work with 60hz squashed > but > hard-edged images. You can pre-process interlaced into fielded image sequence > for work in the comp, but that is an extra step. If you bring it in directly, > I > dont think the comp supports inter-frame work, so working with fielded > interlaced video is not directly supported (but we have a workflow that can > deal > with it). So if you do that, then you need some way to interlace the output > from > that 60hz sequence. > > Keep in mind that many consumer camcorders record interlaced. A large portion > of > our user base is in that range, and want to comp in their spaceship on top of > their back yard plate. I think Blender needs to support input interlaced > video > for the next five years at least, either via a manual pre-process step or ... > a > fully implemented feature set. > > > I think the question is whether Blender needs to be able to GENERATE > interlaced > video. Not using fields on output gives everything a very crisp but jumpy > feel > to it, and so probably actually works well for high-energy TV commercials. I > think it the answer depends on how long the broadcast standard is going to > remain in place. Technically, it was invented before CG and motion > blur/vector > blur, so it may be eclipsed as a blurring technology. As an artist, if I was > doing like a cartoon, I need blur. The question is whether fields would give > a > better result that motion and/or vector blur. I guess it should be put to the > test. Better is a function of visual appeal and render times. > > --Roger > > > Check out my website at www.rogerwickes.com for a good deal on my book and > training course, as well as information about my latest activities. Use coupon > Papasmurf for $15 off! > > > > - Original Message > From: Mats Holmberg > To: bf-blender developers > Sent: Fri, July 9, 2010 11:10:14 AM > Subject: Re: [Bf-committers] Proposal to Remove Features > > I guess the problem with fields nowadays is that they aren't really needed. I > use Blender for creating TV-commercials, all in standard resolution PAL > format, > but have never used fields for anything. The biggest reason for this is that > fields are quite useless when compositing, and compositing is involved in my > every single project. The end result is always interlaced, but that doesn't > mean > field rendering has to be used. Progressive source material works better just > about always in my experience. > > -mats > > > > ___ > 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] Proposal to Remove Features
I guess the problem with fields nowadays is that they aren't really needed. I use Blender for creating TV-commercials, all in standard resolution PAL format, but have never used fields for anything. The biggest reason for this is that fields are quite useless when compositing, and compositing is involved in my every single project. The end result is always interlaced, but that doesn't mean field rendering has to be used. Progressive source material works better just about always in my experience. -mats On 9.7.2010, at 17.46, Carsten Wartmann wrote: > Am 08.07.2010 19:30, schrieb Brecht Van Lommel: >> Hi, >> >> Here's a proposal to remove a number of features before 2.6. I've been > > I used rendering in fields lately and can't belive that all artists will > have no old TV, DV Cams and recorders, rendering for video DVD or for > PAL/NTSC Broadcast at the time. Maybe it can removed in 10 years > > Also in HD we have interlaced formats. > > Carsten > > -- > Carsten Wartmann: Autor - Dozent - 3D - Grafik > Homepage: http://blenderbuch.de/ > Das Blender-Buch: http://blenderbuch.de/redirect.html > ___ > 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] new UV test grid
And as always, why would "made for the professional" mean that it needs to be userUNfriendly? The so called 'pros' who want to do things the hard way, are in fact no pros at all. If one does real work, one has to deal with real deadlines, and will appreciate everything that makes life easier. And Apple is not synonymous to user friendly. -mats On 26.3.2010, at 18.38, loopduplic...@burningtoken.com wrote: > Blender is made for the professional, not for the average computer > user. It reminds me nothing of an Apple application and that makes me > happy. > > On 3/26/2010 8:57 AM, Paolo Ciccone wrote: >> This is (about) how friendly Blender is "out of the box" for the average >> user. >> > > ___ > 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] set "F6" pop-up-panel to pop-up automatically by User Preference's selection
I've come across the same kind of bad popup-examples, from using Linux and osX. As an example, Spaces and popups in osx is a horrid combination. But these examples are just plain bad design and/or bad programming. I don't think the popup in this case needs to be so in-your-face. I liked the mockup William made, it's evidently clear that the information shows better in that mockup then it does hidden away in a toolarea, which in turn might be hidden too. When adding an object, a new popup (or info-area) could be shown on the side of the 3d-view, clearly visible but out of the way, so that one can continue working without paying attention to it. And it should disappear on it's own when not relevant anymore. Also, the information, and the parameters should remain editable after doing basic operations on objects (mainly move, rotate, scale, undo, switch edit/object mode). Cheers, -mats On 18.3.2010, at 0.28, Roger Wickes wrote: > please dont misunderstand. I am all for a well-designed popup, at the user's > option, to execute startup scripts (User-Pref->Execute Autorun Scripts upon > Load: Yes/Always, No/Never, Ask me) > where Ask Me gives a modal popup. > > and the popup is something like "Warning. The blend file you have opened > contains a script set to execute automatically. Do you want to execute it? > Yes / No / Help" with a tag line to disable this notification popup in > User-Pref-.Execute Autorun Scripts. > > --Roger > > > Check out my website at www.rogerwickes.com for a good deal on my book and > training course, as well as information about my latest activities. Use coupon > Papasmurf for $15 off! > > > > > > From: Seppo Tukiainen > To: Bf-comitters > Sent: Wed, March 17, 2010 2:16:51 PM > Subject: Re: [Bf-committers] set "F6" pop-up-panel to pop-up automatically by > User Preference's selection > > > >> Mats Holmberg wrote: > >> I feel the problem really is that the panel is kind of "tucked away". > > > > This is what I ment in the firs place, because we can't deny that current > dependent parameters must be set just after adding the objects/tools in the > scene. > > I don't see why pop-ups are so unwanted by Ton, at least in this case. In > fact they simplifies and speed up the design prosess by allowing designer to > keep focus on the work. Program brings necessary information and parameter's > entry fields in correct place (right there where the focus is). If all are > correct just move you mouse, and panel vanish. Easy and quick! > > Yes, Ton is right that many other programs uses pop-ups, but maybe because > it's the best way to do it. > > This automatic pop-up method is at least the beter way to hadle this, > compared to that bottom-left-corner-panel. So why don't take advantage of > it? Panels are coded there already, just need to insert correct calls! When > the final solution sees daylight, consideration can be done again. > > > >> Mats Holmberg wrote: > >> My biggest concern is around the fact that currently editing important >> properties, like amount of vertices on a circle, has to be done immediately >> after adding the object. So, for example, tabbing into editmode to actually >> see the vertices, destroys the possibilities of changing the amount... and >> one has to start all over again. This was usual in previous 2.4x -series as >> well. > > > There is Outliner, which doesn't have so many functions, yet. Maybe, in the > future, object's properties can be reviewed and readjusted in there !?! > > > > br: Seppo > > > > > >> >> On 17.3.2010, at 11.28, Ton Roosendaal wrote: >> >>> Hi, >>> >>> No, I would not do it this way. A UI should not move focus to >>> (potentially) invisble things without you even knowing it did. It has >>> the danger of inconsistancy, and gets annoying even. A UI should not >>> think for users or assume things either. >>> >>> In my really honest opinion popup form-fill-in-menus are a sign of >>> badly designed tools. It's just easier for the coder, that's why you >>> see them all over. >>> >>> I realize this is just a UI concept, and the daily practice is of >>> course more dirty and needs to find compromises between "get tool to >>> work now" or "not get this tool at all". >>> >>> -Ton- >>> >>> >>&
Re: [Bf-committers] set "F6" pop-up-panel to pop-up automatically by User Preference's selection
Hi, I feel the problem really is that the panel is kind of "tucked away". So a combination of making the panel more visible and also at the same time remember previous settings would be nice. I don't think a popup (eg. at the side of the 3d-view) would necessarily be a bad thing, but I wouldn't like the focus to shift automatically to it. I don't really see how the current way of adding objects differ from the way we did things in 2.4x. Of course it's somewhat better now, but problems remain. My biggest concern is around the fact that currently editing important properties, like amount of vertices on a circle, has to be done immediately after adding the object. So, for example, tabbing into editmode to actually see the vertices, destroys the possibilities of changing the amount... and one has to start all over again. This was usual in previous 2.4x -series as well. Cheers, -mats On 17.3.2010, at 11.28, Ton Roosendaal wrote: > Hi, > > No, I would not do it this way. A UI should not move focus to > (potentially) invisble things without you even knowing it did. It has > the danger of inconsistancy, and gets annoying even. A UI should not > think for users or assume things either. > > In my really honest opinion popup form-fill-in-menus are a sign of > badly designed tools. It's just easier for the coder, that's why you > see them all over. > > I realize this is just a UI concept, and the daily practice is of > course more dirty and needs to find compromises between "get tool to > work now" or "not get this tool at all". > > -Ton- > > > Ton Roosendaal Blender Foundation t...@blender.orgwww.blender.org > Blender Institute Entrepotdok 57A 1018AD Amsterdam The Netherlands > > On 16 Mar, 2010, at 18:56, Jonathan Williamson wrote: > >> Hey Ton, >> >> The "active input" is an interesting thought that could work very >> well if >> implemented right. I could see this working very well if the input >> focus was >> immediately placed in the operator panel, such that you could >> numerically >> input the values without ever clicking a second field. In other >> words, to >> place a new object it would work like this: >> >> 1. Shift + A > Add object >> 2. Input is automatically shifted to operator field (e.g. number of >> vertices, etc) >> 3. Type in value(s) >> 4. Press Enter to confirm >> >> The key would be to remove the need for any mouse movement. >> >> Jonathan Williamson >> http://www.montagestudio.org >> >> >> On Tue, Mar 16, 2010 at 12:26 PM, Ton Roosendaal >> wrote: >> >>> Hi, >>> >>> The design concept was to make tools remember previous settings. >>> Another improvement would be to have a fast way to move 'active >>> input' >>> focus to buttons elsewhere (like right after for tool redo, on a >>> hotkey). >>> >>> Only in last resort we should do things with popups. I still believe >>> you can make an optimal workflow this way, better than popping up >>> stuff all the time. Exceptions are possible, and user configs could >>> allow, of course. >>> >>> -Ton- >>> >>> >>> Ton Roosendaal Blender Foundation t...@blender.orgwww.blender.org >>> Blender Institute Entrepotdok 57A 1018AD Amsterdam The >>> Netherlands >>> >>> On 16 Mar, 2010, at 17:16, Jonathan Williamson wrote: >>> That would also be an improvement. Seppo's idea of creating a user preference for the pop-up is a good one, as there are people who do like like it and just want to add an object immediately. Adding an object immediately can be particularly helpful while in Object mode if you are testing materials or anything like that, then vertex counts aren't your first concern. Jonathan Williamson http://www.montagestudio.org On Tue, Mar 16, 2010 at 11:10 AM, Carsten Wartmann wrote: > Jonathan Williamson wrote: >> I absolutely agree with this. Very seldom do you (or I at least) >> add a > mesh >> object and stick to the default parameters. I nearly always adjust > circles >> and such down to 12 vertices or so. >> > At least the tools should remember the last setting e.g the > number of > verts. > > Carsten > ___ > 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 [26272] trunk/blender/source/blender: Fix [#20821] COLOR MANAGEMENT: Corrupts motion picture files
On 26.1.2010, at 4.49, Matt Ebb wrote: > Revision: 26272 > > http://projects.blender.org/plugins/scmsvn/viewcvs.php?view=rev&root=bf-blender&revision=26272 > Author: broken > Date: 2010-01-26 03:49:30 +0100 (Tue, 26 Jan 2010) > > Log Message: > --- > Fix [#20821] COLOR MANAGEMENT: Corrupts motion picture files There's a another problem with movie import at least on osx. I've had to resort to 2.48 when editing video files for some time now, neither 2.49 nor 2.5 will work. Please see the example here: http://www.artflow.fi/img/video_import.png Cheers, -mats ___ 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 [25897] trunk/blender: Multitouch trackpad 2 fingers gestures implementation
Thanks Damien for making multitouch work! Here's a couple of issues FYI.
I have an issue, where I feel zooming works inverted. In my opinion zooming out
should be done by "pinching" and zooming in by "spreading" your fingers apart.
That's the way it works on the iphone as an example. It also stops working
often, so I need to lift my fingers from the touchpad and try again. All this
combined with the incredible speed it zooms in, makes things quite unusable
for me =)
I'm using a 64-bit Blender build on a 15" MBP from late 2008 running osX 10.6.2.
Another (unrelated) issue has to do with osx spaces that I use all the time.
For some reason Blender becomes unresponsive when returning to it from another
osx spaces "screen". The buttons seem to work ok, but nothing happens in the
3d-window. At some point I got it working, but don't know what I did =) Now I
usually restart Blender after returning to it.
-mats
On 11.1.2010, at 13.14, Damien Plisson wrote:
> Revision: 25897
>
> http://projects.blender.org/plugins/scmsvn/viewcvs.php?view=rev&root=bf-blender&revision=25897
> Author: damien78
> Date: 2010-01-11 12:14:36 +0100 (Mon, 11 Jan 2010)
>
> Log Message:
> ---
> Multitouch trackpad 2 fingers gestures implementation
>
> - 2 fingers scroll (MOUSEPAN / GHOST_kTrackpadEventScroll event) pans/scrolls
> the view
> - 2 fingers pinch (MOUSEZOOM / GHOST_kTrackpadEventMagnify event) zooms the
> view
> And in 3D view:
> - alt + 2 fingers scroll rotates the view
> - 2 fingers rotation (MOUSEROTATE / GHOST_kTrackpadEventRotate) orbits the
> view.
>
> The implementation uses a new GHOST event type: GHOST_kEventTrackpad, that is
> then dispatched as Blender MOUSEPAN, MOUSEZOOM
> or MOUSEROTATE events.
>
> This is currently fully implemented for OSX (GHOST Cocoa fires the new
> events), with auto-detection of the source peripheral, so that a regular
> mouse still sends MOUSEWHEEL events.
>
> Modified Paths:
> --
>trunk/blender/intern/ghost/GHOST_Types.h
>trunk/blender/intern/ghost/intern/GHOST_SystemCocoa.mm
>trunk/blender/source/blender/editors/interface/view2d_ops.c
>trunk/blender/source/blender/editors/space_image/image_ops.c
>trunk/blender/source/blender/editors/space_image/space_image.c
>trunk/blender/source/blender/editors/space_outliner/outliner.c
>trunk/blender/source/blender/editors/space_text/space_text.c
>trunk/blender/source/blender/editors/space_text/text_ops.c
>trunk/blender/source/blender/editors/space_view3d/view3d_edit.c
>trunk/blender/source/blender/editors/space_view3d/view3d_ops.c
>trunk/blender/source/blender/makesrna/intern/rna_wm.c
>trunk/blender/source/blender/windowmanager/intern/wm_event_system.c
>trunk/blender/source/blender/windowmanager/wm_event_types.h
>
> Added Paths:
> ---
>trunk/blender/intern/ghost/intern/GHOST_EventTrackpad.h
>
> Modified: trunk/blender/intern/ghost/GHOST_Types.h
> ===
> --- trunk/blender/intern/ghost/GHOST_Types.h 2010-01-11 11:11:21 UTC (rev
> 25896)
> +++ trunk/blender/intern/ghost/GHOST_Types.h 2010-01-11 11:14:36 UTC (rev
> 25897)
> @@ -151,6 +151,7 @@
> GHOST_kEventButtonDown, /// Mouse button event
> GHOST_kEventButtonUp, /// Mouse button event
> GHOST_kEventWheel, /// Mouse wheel event
> + GHOST_kEventTrackpad, /// Trackpad event
>
> GHOST_kEventNDOFMotion, /// N degree of freedom device motion
> event
> GHOST_kEventNDOFButton, /// N degree of freedom device button
> event
> @@ -373,7 +374,29 @@
> GHOST_TInt32 z;
> } GHOST_TEventWheelData;
>
> +typedef enum {
> + GHOST_kTrackpadEventUnknown =0,
> + GHOST_kTrackpadEventScroll,
> + GHOST_kTrackpadEventRotate,
> + GHOST_kTrackpadEventSwipe, /* Reserved, not used for now */
> + GHOST_kTrackpadEventMagnify
> +} GHOST_TTrackpadEventSubTypes;
> +
>
> +typedef struct {
> + /** The event subtype */
> + GHOST_TTrackpadEventSubTypes subtype;
> + /** The x-location of the trackpad event */
> + GHOST_TInt32 x;
> + /** The y-location of the trackpad event */
> + GHOST_TInt32 y;
> + /** The x-delta or value of the trackpad event */
> + GHOST_TInt32 deltaX;
> + /** The y-delta (currently only for scroll subtype) of the trackpad
> event */
> + GHOST_TInt32 deltaY;
> +} GHOST_TEventTrackpadData;
> +
> +
> typedef enum {
> GHOST_kDragnDropTypeUnknown =0,
> GHOST_kDragnDropTypeFilenames, /*Array of strings representing file
> names (full path) */
>
> Added: trunk/blender/intern/ghost/intern/GHOST_EventTrackpad.h
> ===
> --- trunk/blender/intern/ghost/intern/GHOST_EventTrackpad.h
> (rev 0)
> +++ trunk/blender/intern/ghost/intern/GHOST_EventTrackpad.h 2010-01-11
> 11
Re: [Bf-committers] New Developer Meeting minutes
On 12.1.2010, at 8.39, Nathan Letwory wrote: > 2010/1/12 Erwin Coumans : >> I'm surprised of so much resistance among the Blender developers >> to such a nice build system as cmake. >> >> Thanks, >> Erwin > > We can also reverse the question - we have a very nice and working > SCons system. Why would you want to get rid of the nice system I > created? > > "I'm surprised at the resistance among certain people to such a nice > build system as SCons" Just to comment on this: I know nothing about the hassle that is required for maintaining any of these systems, but from a Blender user standpoint scons is very easy to use. As Nathan said, I do "svn up && python scons/scons.py" and that's all that's ever needed. During the years, I haven't seen anything being even close to that kind of ease of use. Dont' take that away, please! -mats ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] 2.5 UI font
On 9.12.2009, at 2.01, Vilem Novak wrote: > Hello, these are good ideas, but I guess while horizontal layout really is > asking for trouble, there are issues with vertical layout that can be > finished after the proposals, and make everybody reasonably satisfied(at > least 1 working UI)> > solve issue with still-horizontal and long header > possibly tab-ed panels > some more readability and space issues > I guess this list is much shorter and possibly easier to accomplish? I personally could live with a vertical layout, that is a bit more polished. As I said earlier my problem is the header still =) But I don't really understand the talk about horizontal layouts being troublesome because of all the scrolling. The only times I've had to scroll in a horizontal layout are when I do rigging or browse through lists of things like modifiers. But that's something one has to do in a vertical layout as well. In 2.x I never scroll horizontally, because everything fits and is visible as it is. So in a sense the horizontal layout in 2.x works like the vertical layout in 2.5.. just without the need to scroll the header. -mats ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] 2.5 UI font
On 9.12.2009, at 2.38, doug wrote: > Just from another perspective in the changing world of computers. > > The standard screen aspect ratio for new monitors (exceptions exist) is > 16:9 or 16:10. This means that vertical toolbars are more appropriate in > these situations since the leftover realestate is still wider than tall. In certain cases yes, eg when you use one 3d-view. But if you split your view in two, then you will have two narrow views instead. Two views fit much better in a horizontal layout on a 16:9 monitor. Just one example. -mats ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] 2.5 UI font
On 8.12.2009, at 14.37, dw...@free.fr wrote: > > to design issues or inconsistencys. > > With the new design, the horizontal layout > for buttons does not work well, thats > a fact and was planned. > I see your point with the AA-fonts. I too am quite a heavy Blender user and think that the non-AA fonts allow for a much clearer read at small font sizes. I would like to have them back too, as an option. I tried scaling down the fonts to something I'd like to use, and as they are now they just became a mess. With the button layout I thought we now have the option to organize everything ourselves (?) So shouldn't it be possible to fairly easily make different configurations to allow for horizontal layouts. I haven't studied this, but I'm also used to horizontal layouts, mainly because of what you said: it's a PITA to scroll the headers all the time. By no means do I want to undermine the great work that is being done, but from my point of view as a user, these are valid points. -mats ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
