Re: [Bf-committers] Import based on extension
> > The main thing to resolve is how to show operator options (some way to > re-initialize different operator properties when selecting a file with > a different extension). Hmm, would this work? > class ImportByExtension(bpy.types.Operator, ImportHelper): > ... > def check(self, context): # is invoked on every filename change > reload_operator_options(self) # finds via reflection the import operator (and its properties) by file extension > return _check_axis_conversion(self) > def draw(self, context): > draw_operator_options(self) > ... I've actually written some time ago an export operator that uses reflection to "wrap" other export operators ( https://raw.github.com/dairin0d/export-selected/master/io_export_selected.py). It's kinda hacky, but it does the job. I suppose a similar thing can be done for the extension-based import? On Tue, Oct 15, 2013 at 7:02 PM, Jan Albartus wrote: > > I am unsure how practical this workflow would be; > > Import an object using the 'default' import settings. Then have in the > toolshelf (on the left) the import options which a user can tweak. > (changing an option will cause the current imported to be removed and > re-import with the new settings.) This would mimic the way a new mesh, > say a circle, where the user can change the radius/vertices as long as > nothing has been edited. > > The problem becomes then that re-importing the mesh could take longer. > (maybe an apply button?) The advantage could be that instead of making > the selection up-front, it can be done after 'import'. > > I am unsure how practical (from a user's perspective) that would be > though. Maybe setting the import options on forehand is the best way to > go. It would be the first application to change import-settings after > import? > > This has come up before, and it can be done. > > > > The main thing to resolve is how to show operator options (some way to > > re-initialize different operator properties when selecting a file with > > a different extension). > > > > ___ > 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] Surface and Volume modeling with new developed Bezier-Surface math
Oops, my bad -- seems like Catmull-Clark isn't applicable here, Bezier triangles use a different subdivision scheme ^_^" On Sat, Sep 21, 2013 at 8:26 PM, Dima Glibitsky wrote: > Um, Roland -- just curious -- have you seen > https://en.wikipedia.org/wiki/Bezier_triangle or > https://en.wikipedia.org/wiki/Bezier_surface ? It's a surface type with > pretty well-known implementation. > > I'm just another user, but I agree too that Bezier > triangles/patches/surfaces would enable a modeling workflow not really > possible with NURBS or "flat" polygons. > > Theoretically speaking, perhaps it can be implemented as a mesh modifier > that subdivides and deforms polygons based on specific properties of mesh > edges? (to not add a new kind of object data) > I'm not sure if there is a general solution for n-sided bezier polygon, > but at least triangles and quads can probably just use Catmull-Clark > subdivision scheme. > ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Surface and Volume modeling with new developed Bezier-Surface math
Um, Roland -- just curious -- have you seen https://en.wikipedia.org/wiki/Bezier_triangle or https://en.wikipedia.org/wiki/Bezier_surface ? It's a surface type with pretty well-known implementation. I'm just another user, but I agree too that Bezier triangles/patches/surfaces would enable a modeling workflow not really possible with NURBS or "flat" polygons. Theoretically speaking, perhaps it can be implemented as a mesh modifier that subdivides and deforms polygons based on specific properties of mesh edges? (to not add a new kind of object data) I'm not sure if there is a general solution for n-sided bezier polygon, but at least triangles and quads can probably just use Catmull-Clark subdivision scheme. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Patch to add "Show/hide 3D Cursor" functionality
Then, perhaps, instead of "show/hide" toggle there should be several options? 1) Cursor is active and visible 2) Cursor is active but invisible 3) Cursor is inactive and invisible and 3.a) stays where it was left 3.b) stays at the world center while inactive ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Patch to add "Show/hide 3D Cursor" functionality
I've made a poll http://blenderartists.org/forum/showthread.php?295865-Hiding-3D-cursor-use-cases-%28poll%29 Most probably auto-hiding in some modes won't draw any objections, though I'm curious what the results of the poll turn out to be. I'll try to make a patch that hides 3D cursor based in Paint/Sculpt modes in the meantime :-) On Sun, Jun 9, 2013 at 3:44 PM, Ton Roosendaal wrote: > Hi, > > A lot of editing still depends on a 3d cursor to exist, hiding it completely > is not good feature, unless it bypasses every call that uses the 3d cursor. > > For us now, a useful hiding for 3d cursor is in special edit modes like paint > or sculpt (assuming it is not used). > > -Ton- > > > Ton Roosendaal - t...@blender.org - www.blender.org > Chairman Blender Foundation - Producer Blender Institute > Entrepotdok 57A - 1018AD Amsterdam - The Netherlands > > > > On 9 Jun, 2013, at 14:18, Dima Glibitsky wrote: > >> Hi, thanks for the quick reply :) >> Perhaps the main question is, then, if there are any cases when users >> want to hide the cursor in the Object mode. I'll try to ask that on >> the BlenderArtists. >> I can imagine that some CAD-like addons might use the option to >> disable the default cursor to display something more advanced instead >> (e.g. local coordinate axes/planes). In this case, non-coders won't >> have to know about the existence of this setting. >> >> On Sun, Jun 9, 2013 at 2:57 PM, Ton Roosendaal wrote: >>> Hi, >>> >>> If painting and sculpting doesn't require use of the 3d cursor, it can be >>> just hidden by the mode itself? Options and more buttons don't make using >>> Blender easier. We have too many already :) >>> >>> -Ton- >>> >>> ---- >>> Ton Roosendaal - t...@blender.org - www.blender.org >>> Chairman Blender Foundation - Producer Blender Institute >>> Entrepotdok 57A - 1018AD Amsterdam - The Netherlands >>> >>> >>> >>> On 9 Jun, 2013, at 13:27, Dima Glibitsky wrote: >>> >>>> Adds a View3D setting to hide 3D cursor. >>>> >>>> In python: SpaceView3D.show_cursor >>>> In C: V3D_HIDE_CURSOR (#defined as 16 for v3d->flag) >>>> >>>> This feature has been long requested by some users, the main >>>> motivation being that 3D cursor distracts them during the >>>> sculpting/painting process: >>>> http://blenderartists.org/forum/showthread.php?243932-Hiding-3D-Cursor >>>> http://blenderartists.org/forum/showthread.php?266381-Turn-off-3d-cursor >>>> https://www.youtube.com/watch?v=Q5SqZz9PTlQ >>>> >>>> Patch tracker page: >>>> projects.blender.org/tracker/index.php?func=detail&aid=35685 >>>> The patch: http://www.pasteall.org/42942/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 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] Patch to add "Show/hide 3D Cursor" functionality
Hi, thanks for the quick reply :) Perhaps the main question is, then, if there are any cases when users want to hide the cursor in the Object mode. I'll try to ask that on the BlenderArtists. I can imagine that some CAD-like addons might use the option to disable the default cursor to display something more advanced instead (e.g. local coordinate axes/planes). In this case, non-coders won't have to know about the existence of this setting. On Sun, Jun 9, 2013 at 2:57 PM, Ton Roosendaal wrote: > Hi, > > If painting and sculpting doesn't require use of the 3d cursor, it can be > just hidden by the mode itself? Options and more buttons don't make using > Blender easier. We have too many already :) > > -Ton- > > > Ton Roosendaal - t...@blender.org - www.blender.org > Chairman Blender Foundation - Producer Blender Institute > Entrepotdok 57A - 1018AD Amsterdam - The Netherlands > > > > On 9 Jun, 2013, at 13:27, Dima Glibitsky wrote: > >> Adds a View3D setting to hide 3D cursor. >> >> In python: SpaceView3D.show_cursor >> In C: V3D_HIDE_CURSOR (#defined as 16 for v3d->flag) >> >> This feature has been long requested by some users, the main >> motivation being that 3D cursor distracts them during the >> sculpting/painting process: >> http://blenderartists.org/forum/showthread.php?243932-Hiding-3D-Cursor >> http://blenderartists.org/forum/showthread.php?266381-Turn-off-3d-cursor >> https://www.youtube.com/watch?v=Q5SqZz9PTlQ >> >> Patch tracker page: >> projects.blender.org/tracker/index.php?func=detail&aid=35685 >> The patch: http://www.pasteall.org/42942/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 mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Patch to add "Show/hide 3D Cursor" functionality
Adds a View3D setting to hide 3D cursor. In python: SpaceView3D.show_cursor In C: V3D_HIDE_CURSOR (#defined as 16 for v3d->flag) This feature has been long requested by some users, the main motivation being that 3D cursor distracts them during the sculpting/painting process: http://blenderartists.org/forum/showthread.php?243932-Hiding-3D-Cursor http://blenderartists.org/forum/showthread.php?266381-Turn-off-3d-cursor https://www.youtube.com/watch?v=Q5SqZz9PTlQ Patch tracker page: projects.blender.org/tracker/index.php?func=detail&aid=35685 The patch: http://www.pasteall.org/42942/diff ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Please turn off Auto Run Python Scripts by default
I guess I'll barge in the discussion too :) I'm not sure that I see the full picture, but here's how I see the actual use-cases (mostly reiterating the points I've read here): 1) A user gets a .blend from somewhere or someone. Most of the time, the user knows what kind of content is supposed to be there. Either (s)he expects no scripts at all (e.g. it's supposed to be only a model/scene with everything already baked), or (s)he knows there might be some interactive elements (e.g. it's a complex rig or explicitly a script setup). In the latter case, a honest .blend author would (should?) warn that the .blend contains scripts and/or drivers. The idea is, the user usually knows whether there *should* be any scripts, and will get suspicious if they are where they shouldn't be. 1.a) The .blend came from a generally trusted source (Blender Cookie, Blend Swap, fellow artist). If the file does something malicious, it won't spread, since the source is known and can be quickly taken down. 1.b) The .blend is of unknown origin or came from some shady site (I suppose that's the situation Ton is afraid of -- the proliferation of .blends due to the Blender's popularity). In this case, the "takedown" approach isn't really possible, but the user *should always* be suspicious if such file contains any bit of Python code, and probably avoid such files at all (just like with the .doc files). So, as I see it, normal users are generally safe if they stick to trusted sources and know whether any .blend contains Python code. Perhaps a big warning at the Blender download page "Don't open .blends with Python if you don't trust the source!" would help. Of course, a targeted/random one-time attack might still cripple a couple of blenderheads' systems, but, as it was already mentioned before -- who would bother? (Obsessive blenderhead-hating trolls are the only ones I can think of.) Even if .blends would become as ubiquitous as pictures (e.g. due to 3D printer sitting in every household, or BGE becoming more popular than Unity), this scenario still avoids .blend-trojans/viruses if users are properly warned and have a bit of computer common sense. 2) The case of Blender developers or similar folks who *have* to open .blends from unknown people. They are more susceptible to the targeted attacks, and "This file contains Python!" warning won't help them much. But these folks are well aware that every user-submitted .blend they open might do something bad, and they are tech-savvy enough to take defensive measures (inspect the Python code before allowing it to run, or even open the .blend in a virtualized environment). Summing up: it's simply a matter of Pareto principle. "Shifting responsibility to users" is an obvious (and easy to implement) first step to security, which takes care of 90% of (currently purely hypothetical) Python-based attacks. Properly forking/sandboxing Python decreases the number of vulnerabilities, but requires a considerable undertaking by the Blender devs. Switching to an inherently safer language (Lua) would probably require at least as much effort, and leave the userbase smaller and quite displeased. The question is, where to draw the line? Hope this makes some sense :-) Dima. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] GSoC 201 - Automatic Skeleton Extraction
Can this method be used for approximate convex decomposition of characters (or even arbitrary complex models)? It would be useful too. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Make Parent - shouldn't it work differently?
+1 to Bassam Kurdali's proposal :-) ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Images in Panels..
> you can use bgl to load your own textures on top of quads drawn by bgl. So > yes its possible, but not simple, but also not difficult. Also you will also > have to handle scrolling, since the bgl draw is separate from Blender main > GUI , so that means a serious amount of code. But if you don't mind the extra > works it won't be very hard. Bgl also will give some cooler tricks than > Blender GUI because bgl is basically opengl 1.1 wrapper, so that gives some > extra power to the coder. dimitris chloupis, is there any example of such a system? As far as I know, Blender's python API gives no information about panel's scrolling and layout, so even with bgl the addon-developer simply doesn't know *where* to draw the quads. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Proposal on Default Settings
My 2 bits: trackball has always gave me frustrations, because I ended up looking on the scene "lying on the floor"/upside-down after every view rotation :) Manipulator is very useful, because you can see in what coordinate system you'll be transforming the objects, or what direction the object's axes are pointing to. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] API: How to get a list of running scripts?
Remigiusz, then how about incrementing a global variable each frame? Can a new instance wait one frame and then actually launch if the value of the variable hasn't changed? Anyway, seems like I'm the only one responding to this thread, and I'm in no way an expert... Have you tried to ask main developers in the IRC directly? P.S. As I've learned recently, in 2.63 (or maybe even 2.6+), there are bpy.app.handlers.scene_update_pre and bpy.app.handlers.scene_update_post -- these event handlers are invoked each frame (not sure if this behavior will persist, though). It's possible to get the list of the handlers, so I guess in recent Blender versions your idea can be implemented. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] API: How to get a list of running scripts?
What is your script doing? Some realtime background processing? I'm not familiar with 2.49 API, and I'm not sure if this helps your case, but here's my suggestion: perhaps you can pass all the relevant data to the new instance of the script (which would continue the job), and the old one would shut down itself? I used a similar approach during the development of one of my scripts, though it was 2.5+ API. For what reasons are you still using 2.49, by the way? ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] API: How to get a list of running scripts?
Do you mean the Python API? Seems like it's not possible yet... But I guess in your case, you can just have a global variable in the script (or add some property to a WindowManager) and set it to True/False accordingly. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Procedural generation for summer of code!
Hmm, how about parametric modeling? Sort of like a blend of macro, modifiers and drivers: 1. user records a sequence of operations (the end result must be one or more objects) 2. user can change parameters of any constituent operator at any time afterwards (thus regenerating the object(s)) 3. user can modify the operator node graph (add/delete/reconnect operator nodes) at any time afterwards (thus regenerating the object(s)) 4. user can declare "high-level parameters" that drive some parameters of constituent operators Implementing it as a Python addon currently is not feasible, for the following reasons: - from Python, there's no way (or at least I couldn't find one) to monitor what operators are being successfully applied (if operator has been canceled, it shouldn't be recorded; if operator has finished, we must use values of arguments with which it finished) - "parametric" object must be a special kind of Object which can be modified only by changing the operator node graph and/or its parameters (though user can convert "parametric" object to normal object(s) in backwards-incompatible way, like in curve->mesh conversion) - regeneration of such object requires special handling of context -- to have reproducible results and to avoid side-effects in the main scene, the operator node graph must be applied in a separate "pocket dimension" with fixed initial conditions Parametric modeling is probably most useful when you need many similar objects with some variability (houses in a village, armada of pirate airships, etc.), or when you want some animated complex fractal effects in a video. Addons like sapling/ivygen/masonry can benefit from such mechanism too, since it would allow to edit their parameters not just immediately after creation. Also, parametric generation may aid procedural generation. It's just a rough description, but I hope the idea is clear :-) ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Change Representation and Initialisation of Matrices to Conform with Standard Notation
By the way, how slices would be handled in this case? If I recall correctly, currently you can write e.g. matrix[0] to get a 4-vector of X-axis of transform matrix, or e.g. matrix[2][:3] to get 3D-vector of Z-axis. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Proposal to exclude tool settings from Global/Mesh Undo
In most of the cases, changes to ToolSettings push undo stack, which
has the following impact on workflow:
1) To undo/redo meaningful changes to scene contents, user often has
to go through a number of steps that don't change anything in scene
("meaningless" steps from the user's point of view). In such cases,
the side-effect of changing tool settings on the way is usually
undesirable and even hindering.
2) Another bad side-effect is that any change to tool settings makes
it impossible to redo currently undone actions.
In short, users are focused on content manipulation, so
non-content-related history pushes usually just get in the way and
unnecessarily pollute undo history.
I suggest that in this concern Blender should behave similarly to
other applications (e.g. GIMP), where each undo history step is
related to the actual modification of content.
3) On the other hand, sometimes it is convenient to have a history of
some (e.g. brush) settings. To be more specific, these are colors and
slider-regulated properties, such as Weight, Radius, Strength, Jitter,
and so on (because it takes more effort to set them precisely).
However, even in this case they should have a separate history -- of
the "recently used" type, like Colors history in MyPaint.
Actually, there are already precedents of non-undoable/redoable tool
settings. Besides the 3D cursor (though it's not in ToolSettings, it's
still separate for each scene), they include:
- ToolSettings.use_grease_pencil_settings
- ToolSettings.edge_path_mode
- ToolSettings.edge_path_live_unwrap
- ToolSettings.normal_size
Even though they push undo stack, they do not change on undo/redo.
Maybe there are others as well, I didn't check each of them.
So, summing up, the proposal is the following:
- Changes to ToolSettings shouldn't be recorded in Global/Mesh Undo
history, and shouldn't change on Undo/Redo. This may be as well
generalized to other settings that don't modify the content (e.g.
display settings, like Mesh.show_all_edges or
Mesh.show_extra_face_area).
- Introduce "recently used" option for Color & slider-regulated
properties. For example, there could be a submenu with recent values
available when right-clicking on the slider/color.
P.S.
I have also noticed that some Mesh parameters don't change on Undo/Redo too:
- Mesh.use_mirror_x
- Mesh.use_mirror_topology
- Settings in Mesh Display panel
However, use_mirror_x and use_mirror_topology are undoable/redoable in
Weight Paint mode (perhaps there is a bug?). As for Mesh Display
settings, I think it would be logical to make them not push undo stack
;-)
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Display modes for 3D-View from user perspective
There is an option to display shadeless textures in solid mode (in Display subpanel, toggle "Textured Solid")... Lighting-only mode seems to be really absent, though. I'm just a regular Blender user, but I think having all shading-related settings in one place would be nice. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Cycles idea
How about an outline of active selection being superimposed on top of Cycles rendering? I guess that may be helpful too :-) ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
