Re: [Bf-committers] Compositor linker error
Martin Bürbaum wrote:
> Anyway, to be sure I did a clean checkout in a fresh directory and the
> compiled again.
> Unfortunately I still get an error with libbf_composite.a.
>
> user-config.py: http://pastebin.com/H4ZKFq3H
>
> Console output of scons: http://pastebin.com/i6Hnte9c
Nevermind, I've found the problem. Some of the paths are too long (even with a
very short root dir).
If anybody else has the same error ("scons: unknown OSError exception code 0 -
'C:\WINDOWS\System32\cmd.exe': Error") the instructions below work for me!
Here's the patch if anybody is interested: http://pastebin.com/RuY94FtE
Quote from T.K. on the blenderartists forum:
"The "unknown OSError exception code 0" is caused by the fact that
a command line to create libbf_freestyle.a by means of the "ar"
command is very long. The reason why the trunk compiles without
the error is likely that there are no libraries to be created with
that long command lines.
See http://www.scons.org/wiki/LongCmdLinesOnWin32 for a workaround
for the long command line issue in Windows. In short, you need to edit
BlenderSVN\blender\scons\scons-local-1.2.0.d20090223\SCons\Platform\win32.py
and replace the spawn() function with the following code:
SNIP
Source:
http://blenderartists.org/forum/showthread.php?89986-Freestyle-for-Blender/page32
Cheers,
Martin
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Compositor linker error
Antony Riakiotakis wrote
> The easiest way is to delete the "build" and "install" directories, next to
> the blender svn directory.
Thank you for the hints, I just realized why the "clean" command didn't work.
My build directory was set wrong. scons tried to delete a lot more (e.g. ".svn"
stuff).
Anyway, to be sure I did a clean checkout in a fresh directory and the compiled
again.
Unfortunately I still get an error with libbf_composite.a.
user-config.py: http://pastebin.com/H4ZKFq3H
Console output of scons: http://pastebin.com/i6Hnte9c
I'm not sure if the "Error 127" is a problem with my PATH, but here it is:
http://pastebin.com/MNaCmTsq (It was never a problem before, and has not
changed)
Thanks again,
Martin
---
Not sure if this is related ...
For some reason there were "bad" files created in my previous source directory.
Sadly I deleted some of them and I do not know how they were created and I
could not reproduce it yet.
*) There were some 0 kb files (mostly *.a or *.o files IIRC with ' around them:
'libbf_x.a')
*) And then there was a strange directory called "(":
http://pastebin.com/PNmDaWmx
This might be because of my misconfiguration, but I thought I'd let you know.
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Compositor linker error
Antony Riakiotakis wrote: > Is this on a clean build? The directory structure is kind of old, so I'd have to say no. Is there a way to tell scons to "make clean"? "scons clean" just gives me errors (see below). Otherwise I'll try to checkout everything in a separate tree - That might take some time since the connection is pretty slow here. Thank you, Martin -- > python scons\scons.py clean scons: Reading SConscript files ... Command-line arguments No command-line arguments given Command-line targets clean Using config file: build_files\scons\config\win32-mingw-config.py Using user-config file: user-config.py Clearing installation directory: X:\..\source\trunk\install\win32-mingw\2.66\scripts Build with parallel jobs: 1 Build with debug symbols: True Cleaning build dir... clean dir X:\..\source\trunk\blender\source\.svn WindowsError: [Error 5] Zugriff verweigert: 'X:\\..\\source\\trunk\\blender\\source\\.svn\\all-wcprops': File "X:\..\source\trunk\blender\SConstruct", line 421: shutil.rmtree(B.root_build_dir+entry) File "C:\Program Files\Python26\lib\shutil.py", line 221: onerror(os.remove, fullname, sys.exc_info()) File "C:\Program Files\Python26\lib\shutil.py", line 219: os.remove(fullname) -- ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Compositor linker error
Antony Riakiotakis wrote: > Scons builds fine here. There have been a few fixes there. Is this on > latest svn version? Yes, the latest svn revision from when I wrote the previous mail was r56106 (trunk & lib/mingw32). Just checked out the most recent revision (r56125) to make sure. Same error(s). > Can you share your configuration file? The active flags in my user-config.py file are below. The basic configuration is like suggested in the wiki: http://wiki.blender.org/index.php/Dev:2.5/Doc/Building_Blender/Windows/MinGW/Scons Removing all flags except for BF_BUILDDIR and BF_NUMJOBS gives the same errors about libbf_composite.a > Also, don't forget, for MinGW 32bit we support only gcc 4.6. My gcc version is 4.6.1 Also: The file source\lib\libbf_freestyle.a is missing completely. May be the same for the libbf_composite.a file - I could not check that yet. Cheers, Martin user-config.py BF_BUILDDIR='X:\\..\\source\\trunk\\blender\\source' WITH_BF_JACK = False WITH_BF_SNDFILE = False WITH_BF_FFMPEG = True WITH_BF_COLLADA = True WITH_BF_OPENAL = True WITH_BF_SDL = True WITH_BF_OPENEXR = True WITH_BF_JPEG = True WITH_BF_PNG = True WITH_BF_TIFF = True WITH_BF_GAMEENGINE = True WITH_BF_PLAYER = True BF_DEBUG = True BF_NUMJOBS = 1 WITH_BF_COMPOSITOR=False # <-- The workaround for the compositor problem. gcc version output > gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=c:/program files/mingw/bin/../libexec/gcc/mingw32/4.6.1/lto-wrapper.exe Target: mingw32 Configured with: ../gcc-4.6.1/configure --enable-languages=c,c++,fortran,objc,obj-c++ --disable-sjlj-exceptions --with-dwarf2 --enable-shared --enable-libgomp --disable-win32-registry --enable-libstdcxx-debug --enable-version-specific-runtime-libs --build=mingw32 --prefix=/mingw Thread model: win32 gcc version 4.6.1 (GCC) ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Compositor linker error
Sorry to resurrect this thread, but I recently tried to compile Blender again with scons & win32-mingw and still encountered this problem. Between my last post and now I used a workaround for the problem: WITH_BF_COMPOSITOR=False. This workaround worked fine until recently (introduction of freestyle into trunk). Now I have the same problem with freestyle and THAT I can't ignore. --- ... Linking library ==> 'libbf_freestyle.a' scons: *** [source\lib\libbf_freestyle.a] Error 1 scons: building terminated because of errors. --- Again, I can find no further error messages that would help narrowing the problem down. Any tips on what to look out for? The second thing I noticed is that when disabling freestyle (WITH_BF_FREESTYLE=False) I get the following error: --- ... Linking program ==> 'makesrna.exe' source\source\blender\makesrna\intern\makesrna.o:makesrna.c:(.data+0x140): undefined reference to `RNA_def_linestyle' collect2: ld returned 1 exit status scons: *** [source\makesrna.exe] Error 1 scons: building terminated because of errors. --- Cheers, Martin Fullquote FYI: > Betreff: RE: [Bf-committers] Compositor linker error > Gesendet: Dienstag, 12. Juni 2012 um 11:55 Uhr > > I also ran into this problem on my Windows machine. My setup is pretty much > identical to Justin's. > > I'm not sure how to debug errors like this (or simply get more info about the > error). > > Is there anybody who got this to compile/link yet? or at least give a hint > where the problem may be? > > Thanks in advance, > Martin > Justin Dailey wrote: >> I haven't tried building blender in a week or two. Now when I try >> to build it, I get a linker error trying to link "libbf_composite". >> I'm using XP-32bit, mingw32, and scons. If I missed something on >> the mailing list that already addressed this, I apologize. >> Everything builds fine just prior to the merge of the Tiles branch. >> I don't get any errors prior to: >> >> Linking library ==> 'libbf_composite.a' >> scons: *** [C:\BlenderSVN\build\lib\libbf_composite.a] Error 1 >> scons: building terminated because of errors. >> >> I am just wanting a simple build of blender so any way I can either >> fix this issue or configure it some way to bypass it would be great. >> Any help would be appreciated. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Cursor to center of mass
Just FYI - I did something similar ("Snap Cursor to Centroid") as a script a
while back.
http://projects.blender.org/tracker/index.php?func=detail&aid=30299&group_id=153&atid=467
Cheers,
Martin
Original-Nachricht
> Datum: Mon, 19 Nov 2012 19:00:23 -0300
> Von: Juan Pablo Bouza
> An: bf-committers@blender.org
> Betreff: [Bf-committers] Cursor to center of mass
>
> Hi! The addition of the "center of mass" option for object origins is
> really cool!
>
> Now, there are many times in rigging when you need the center of the
> object to be at 0 0 0, specially for exporting meshes. So, in these
> cases, the "origin to center of mass" option would not be used.
> Nevertheless, the center of mass options would be really usefull for
> placing objects such as bones...
>
> So, I propose to add the center of mass option also in the Cursor
> snapping menu (shif+S). That would be "cursor to center of mass".
>
> Cheers!
___
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?
>From a user perspective I agree with your assertion. For a possible solution I'd suggest something like a [Global | Local] switch in the "Transform" dialog(s). That should be pretty universal. I'm not sure if this is easily possible from the programming side though. Best regards, Martin ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Compositor linker error
I also ran into this problem on my Windows machine. My setup is pretty much identical to Justin's. I'm not sure how to debug errors like this (or simply get more info about the error). Is there anybody who got this to compile/link yet? or at least give a hint where the problem may be? Thanks in advance, Martin Justin Dailey wrote: > I haven't tried building blender in a week or two. Now when I try > to build it, I get a linker error trying to link "libbf_composite". > I'm using XP-32bit, mingw32, and scons. If I missed something on > the mailing list that already addressed this, I apologize. > Everything builds fine just prior to the merge of the Tiles branch. > I don't get any errors prior to: > > Linking library ==> 'libbf_composite.a' > scons: *** [C:\BlenderSVN\build\lib\libbf_composite.a] Error 1 > scons: building terminated because of errors. > > I am just wanting a simple build of blender so any way I can either > fix this issue or configure it some way to bypass it would be great. > Any help would be appreciated. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] patch tracker
Tom M wrote: > Anyone who has added a comment or is assigned to the patch/bug will > see any new comments. So ie your please close comment was seen by me > and i closed the patch. In this case yes, but I was thinking in more general terms. If nobody with the rights to change the tracker is notified or reads it. Example: If I had posted the "please close" comment a few days ago and you hadn't commented or seen the tracker. Although I guess this is an extreme case, I'm just wondering what the best procedure in the tracker is. I hope I'm not talking nonsense here :-) Cheers, Martin ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] patch tracker
Tom M wrote: > for old patches (2010 and earlier) I've requested the author to > respond whether the patch is still useful or should be closed. [SNIP] On a related note (bug & patch tracker): One thing I noticed is that the creator of the tracker can not change the status (e.g. to closed) later on. (Although maybe it's just for me) Is this intended? If the tracker is not assigned to anybody will e.g. a simple "please close" request in the comments be heard? Cheers, Martin ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Crash when rendering with blender trunk MinGW/SCons/win32
Antony Riakiotakis : > Usually agressive optimisation may cause this. Try lowering > it and see how it behaves. Ohhh, perfect catch! Disabling the very first optimization "scons --help" listed as enabled turned out to be the problem. Running SCons with "WITH_BF_RAYOPTIMIZATION=False" helps. Many thanks, Martin ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Crash when rendering with blender trunk MinGW/SCons/win32
I am compiling current blender trunk (rev. 43662 right now) myself using with MinGW (win32) and SCons. Now compilation works [1] and Blender runs fine, until I try rendering (internal & cycles alike) - then I get a crash. Roughly translate the windows error message says that Blender tried to access memory at address "0x". Unfortunately I have problems installing MSVC2008 on this machine, so I can't debug this myself. So my question is: Does anybody else use MinGW& SCons on win32 and/or has anybody encountered this crash? My guess is that it's an error on my side (lib?), but how do I find out what's wrong? Cheers, Martin [1] Compilation log here: http://www.pasteall.org/28515 ___ 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 [43428] trunk/blender: Carve booleans library integration
Hi Sergey, And here's an example (2 co-planar cylinders) where carve fails completely right now. http://www.pasteall.org/blend/11042 I think it's possibly because of the coplanar faces or the colinear edges. Blender trunk 43555, compiled by myself on Win32. Cheers, Martin Sergey Sharybin > Hi, > > Yeah, that's indeed not nice topology. Will look into this thing. > > On Wed, Jan 18, 2012 at 4:48 PM, "Martin Bürbaum" > > http://www.pasteall.org/blend/11020 ___ 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 [43428] trunk/blender: Carve booleans library integration
Hello Sergey, first of all many thanks to you and Tobias for the work on the carve/boolean code. I know your request was directed at Carsten, but I can provide an example where the boolean code still has some issues. http://www.pasteall.org/blend/11020 The file was created with Blender trunk revision 43484. I used a default cube and a default cylinder and joined them with a boolean "Union" modifier. (The same problems exist when using "Difference" and "Intersect".) The applied mesh looks quite nice on first glance, but the joint seam is composed of "bad quads" (e.g. zero surface polygons, 3 points in a row, concave). Some of these are marked with grease pencil arrows, but there may be more - I suggest following the seam and check every polygon (especially on the cube) to find strange behaviour. I'm not sure how easy it is to improve this, I just wanted to point out the things I've seen. Cheers, Martin Original-Nachricht > Datum: Tue, 17 Jan 2012 22:52:03 +0600 > Von: Sergey Sharybin > An: bf-blender developers > Betreff: Re: [Bf-committers] [Bf-blender-cvs] SVN commit: > /data/svn/bf-blender [43428] trunk/blender: Carve booleans library integration > Hi, > > Well, if you'll provide some files where you think new booleans fails > when they shouldn't it might help a lot. Me or Tobias (Carve's author) > can try to improve something. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Adding objects?
Juhana Sadeharju wrote: > (1) Add object places the object as aligned to screen. > How to place the object to world-space? E.g., on the ground > plane at center of screen with the zero rotation? If you want this to be the default behaviour: Make sure you have "Align To" set to "World" (not "View") in the "Editing" section of the User Preferences. http://wiki.blender.org/index.php/Doc:2.5/Manual/Interface/Configuration/Editing#New_objects If you want to control it for each added object: Select/Deselect the "[ ] Align to View" checkbox in the toolbar after adding the object. (To the left of the 3D View. Press [T] to show/hide it and look for the "Operator" panel at the bottom.) > (2) I added objects with Add (opened Add menu multiple times) > and now the objects are selected as a unit, not separately. > How to Add multiple objects and have them as separate objects? Again, see what the setting is for "New objects" in the "Editing" section of the User Preferences. http://wiki.blender.org/index.php/Doc:2.5/Manual/Interface/Configuration/Editing#New_objects Please be sure to ask questions like this in the "Support" section of the BlenderArtists forum first. http://blenderartists.org/forum/forumdisplay.php?7-Support This mailing list is focused on Blender development. Often things like this are not bugs, but simply a difference in the configuration/usage. Cheers, Martin ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Proposal for "View Docs" on Right Click
Sean Olson wrote: > Additionally, we would have to decide on exactly how to do this UI wise. > There are a number of options. > > 1. Additional Menu Item - So we would have 'View User Docs' and > 'View API Docs' > > 2. Tie User Docs and API docs together in wiki. So if you go to > 'View Docs' there would be a link from the API docs to the User > docs and vice versa > > My personal preference is the additional menu item. I feel that Users > rarely want to look at API docs, but devs often look at both. If I'm allowed to chime in here, I agree that the 1. option would be a good idea. But I'd call the menu options simply "Help" for the User doc and "View/Show development documentation" for the API stuff etc. That looks clearer to me at least and probably the average user as well. (Personally I use the API docs at times). Option 2 "Tie User Docs and API docs together in wiki" probably would create either a mess or would branch out in the wiki anyway - depending on the implementation. Cheers, Martin ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] UI changes from cycles branch
Brecht Van Lommel wrote: > Here's a patch with a subset of the UI changes in the cycles branch > that I'd like to merge into trunk. Are there any objections to this? > > Before: http://www.pasteall.org/pic/show.php?id=19452 > After: http://www.pasteall.org/pic/show.php?id=19453 Below are my opinions about the patch, made by comparing the two screenshots. So this obviously excludes issues & improvements that might show up in different areas of Blender. Background: I program python add-ons and use Blender in my spare time. I agree with Ton that some things should be handled by allowing custom designs, but some things with the default style could & should be improved nevertheless. -- Positive > * Panel header changed look & smaller +1 Love the change of the headers in the patch, makes it easier (for me) to scan. The current seperator-line + bigger text feels like clutter, never was a fan of that. Not sure if the size change of the text is neccesary, but the "bar" helps a lot IMO. I'd really like to see this in the default style Blender. > * Toolbar/properties expand button look Big + The current look seems seems rather floaty. Again, I'd like to see this in the default style Blender. -- Negative > * Remove button emboss > * More subtle colors and gradients on buttons http://www.pasteall.org/pic/show.php?id=19453 -1 for the end result (not sure if the emboss is directly involved) It is already a fine line with the current default design. In the patch I can NOT differenciate between e.g. buttons and a text box on a first glance. After looking for a few seconds one can deduce what's what, but that's not a good design decision IMHO. > * Screen splitting widgets look > * Black arrows on menu button I'm more or less indifferent about these, but I imagine that this will cause other people trouble. (e.g. Sometimes hiding interface options for beginners and in the worst case even experienced users). Increasing the contrast just a tad might help a lot here (darker or lighter). I'm certain there exists a good middle ground. -- Indifferent > * Remove emboss on areas and regions Don't care, I think both look nice and usable. Only problem that I could imagine would be if the "grab" area of the edge gets smaller as well? That would be bad, but not a problem with the graphical design. Cheers, Martin ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Proposal: Object creation
Martin Poirier wrote: > It would be simpler to add the missing python wrapper for > modifiers (if any are missing) than hacking the operator system to do > something it's not meant to. > > Modifying existing python scripts for the new api should be easy. Python modifiers: Yes, definitely a way to do it [1]. Do I understand it correctly that all the current python scripts and blender-internal functions be reused (not duplicated) with some modifications? If not that would be far from optimal since you'd need to recreate every single mesh creation script as a modifier (or something to that extent). Which is ... uhm, not really the goal I had in mind with my proposal :-/ So if this is implemented using modifiers then there ought to be a way to reuse all the existing creation code. I seem to be missing something here. How is that simpler or rather better than my proposal? Don't take this the wrong way, I just want to understand the technical background. I know very little of the current architecture/code in Blender. One way to implement my original proposal is to create a _new object type_ that uses mesh creation operators for its content. (See also the response by GSR [2].) The object properties would be 1:1 representations of the parameters the operators need and the operator is executed each time they change. Is that not a way how operators should work/be used? Maybe I just don't understand them correctly. Cheers, Martin [1] Minor nitpick: The name "Modifier" implies that they modify things, not create from scratch. :-) Even if there is geometry created, there already was some to begin with. So you'd "modify" something in order for something new to be created ... kinda unintuitive. [2] http://lists.blender.org/pipermail/bf-committers/2011-October/033790.html ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Proposal: Object creation
> This reminds a lot of what happens with NURBS, Meta or Text > objects. So one Blenderish approach would be to add a new object type > that has high level controls and can be converted into meshes when > needed. It would fit the user workflow 100% and you have other code > examples to follow. Yes, that's one way to implement the proposal. It should also enable us to reuse existing geometry-generation code IMO (be it blender-internal or from scripts). Not sure how easy that is on the coding side though. Cheers, Martin ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Proposal: Object creation
"Αντώνης Ρυακιωτάκης" wrote > You would need a primitive modifier for every primitive or an > primitive uber-modifier where you select the primitive and get the > appropriate setting below(It would get a bit crowded with switch-case > statements in the C and Python code so maintenance wise it may be > tricky). I think the latter is preferable, though the whole system > with modifiers does feel a bit weird for this use case. I am not sure > if a modifier can be coded in Python, making this system hard to > extend too. Ideally one would code a custom primitive (see for > instance ivy generator) and expose it through Python without delving > too much into c. Exactly my concerns & thoughts wbout the "modifier way". Martin ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Proposal: Object creation
Martin Poirier wrote: > You can add and remove modifiers and change their properties > as easily as operators. I'm not sure that we are talking about the same thing here. What I mean is if we e.g. create a new script that adds a certain geometry, how easy will it be to add this as a modifier? Where is the mesh creating process done? My original proposal implied the re-use of existing operators for that task in one form or another. Cheers, Martin ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Proposal: Object creation
Martin Poirier wrote: > The cleanest way to do that without having to hack anything in the > operator system is having primitive modifiers. > > Modifiers already have all the properties you need and more (being able to > add more modifiers to the stack without losing your editable properties). Sounds interesting. Just one thing: What about support for scripts? These are the ones that would profit most of the change. How would they be able to plug into the modifier stack? Cheers, Martin ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Proposal: Object creation
> The appeal of modelling in blender is that it's just so much more > immediate than other tools. > Having the object locked to only its initial creation parameters when > entering edit mode sounds very cumbersome. > How will you make it not so? I _mostly_ agree when it comes to primitives. But that still doesn't mean that the option of non-destructive behaviour is not useful :-) Any idea to make this as transparent as possible is welcome. The first idea I have would be to make the conversion completely transparent. I.e. as soon as you change the content in edit mode you get an indicator that the object can now be modified, but parameters can not be tweaked anymore. (A simple undo would revert this of course.) Another way would be to make the "locked" creation an optional/separate process. > Also, how will your system work if I add an object whilst in edit mode? Nothing changes here. Adding stuff in edit mode (i.e you already have the object unlocked) would behave like it does now. You can redo operators, but you can obviously not change the parameters in the long run. > There was a python solution a while back that would allow you to do > transforms etc and then go back and change the creation parameters as > long as you hadn't edited the created mesh. > (entering edit mode was the key there I believe) :-D That was what I referred to in my original mail - that is/was my code. It was canned because of various issues. The main problem was basically that the framework I'm proposing right now does not exist yet. And no, there was no locking involved in the scripts (or "smart behaviour" like recognizing if edit mode was entered). It was more of a workaround than solution. This proposal aims for the latter. > IIRC it only worked on primitives created in python rather than the > native ones, but if that worked for all primitives It strikes me that > is a much more "blender" solution... Please keep in mind that internally there is no difference if the object was created by Blender directly or from python. So having a framework that _supports_ this new way of creating objects will then enable us to use it to do useful stuff with it. IMO it's not supposed to be a replacement, other may have a different view on it though. Worst case: I'm all for keeping the existing way of adding object if we can't find a decent way of making this transparent. > Seriously though, in "real world" use rather than theoretical tests > does anyone use a primitive /without /editing it? for me that's so > rare i'd class it as almost never. The proposal is not focused on primitives-only, it's a general view on object creation. As you mentioned already there are a lot of more complex mesh scripts that could benefit from the integration of a system like this. I personally don't do it often with _primitives_. But IF I do it's a bit of a pain checking the geometry to see how the mesh looks and the re-create with exactly the same geometry but one parameter tweaked :-/ Workflow of users differ heavily, so I assume other people use it even more than me and not at all. Discuss! Cheers, Martin ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Proposal: Object creation
Thomas Volkmann wrote: > +1 > That means for example, that you can change the segmentsnumber of a > sphere at any later time (as long as you didn't do anything else to it). > Did I get that correctly? Pretty much, yes. Not sure how the needed changes would break existing tools and scripts, though. e.g. The generated mesh data would still be there, but scripts can not edit them (or depending on implementation, not find them at all). Cheers, Martin ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Proposal: Object creation
Follow up of the "redo operator with last used settings (patch)" thread http://lists.blender.org/pipermail/bf-committers/2011-September/033725.html I propose a new way of handling newly created objects in Blender. I'm sure this may not have a high priority right now, but discussion and planning is never a bad thing IMHO. I'll not go into detail how this should be implemented since Blenders internal architecture is still new to me. I'll add my basic ideas though. C&C welcome (especially from the coding and framework perspective). -- OBJECT CREATION Everything created with an "Add" operator is initially locked from editing and can only be changed by tweaking its parameters (see below of editing). My basic idea would be to store a unique identifier (operator name?) and the defining parameters (operator parameters?) in that object somehow. Maybe making this its own object type (e.g. "Generated") would work? PARAMETER EDITING The parameters of the object can then be tweaked (in object or edit-mode, see below) to ones linking. I imagine this would be done by taking the the operator and parameters and "redo" them. CONTENT EDITING After creation you can enter edit mode, but you will not be able to change anything except the parameters. When one wants to edit the data of the object directly (mesh/curve/etc.) it will be converted to an "editable" object. That means that after that the object behaves no different than it does right now in Blender. This can be done automatically (with a small prompt to the user) or explicitly by "unlocking" (i.e. converting) the object. I'm not sure if dropping the operator & parameters it was created with is good or bad at this point. -- If anybody is familiar with the way C4D handles newly added objects of certain types - this is pretty similar to that. I implemented a very crude version of this behaviour when we started doing addon scripts, but the script could not enforce the lock (making this system kinda wonky). Cheers, Martin ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] redo operator with last used settings (patch)
> A few times this has been requested on IRC so I decided to look into it. > This is so if you add a cylinder for with 3 sides, the next time you > add it will use 3 sides again. Can't say much about the code, but from a user perspective a small button to "Reset to default values" might be a good idea. If this is supposed to be the default behaviour that is. Otherwise the change sounds pretty useful - especially for repeated use of more complex operators/parameters. Cheers, Martin ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Yet another compile patch for MinGW
> Hey, thanks for applying this. I forgot to mention that 36603 is solved by > this patch too. MinGW does know about RIM_INPUTSINK but it needs WINVER > defined as 0x0501 in order to define it in winuser.h I can confirm this. Compilation under MinGW (Windows XP, 32 bit) is working again. The error about the undefined RIM_INPUTSINK is gone. Cheers, Martin ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Sensor Size
Ejner Fergo wrote: > I am of course hopeful to see this get some attention from the > developers, and appreciate you guys seeing the importance of this. I > just don't know how to proceed with this to make an inclusion in trunk > more likely. It would be really nice to hear some opinions from those > with authority. I am not a blender developer (sorry, no authority here), but I think a good start would be to upload the latest patch to the code review tool [1]. And link that in the bug tracker. (http://codereview.appspot.com Example Review: http://codereview.appspot.com/4280080 Mailing List: http://lists.blender.org/pipermail/bf-codereview/ ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] bump mapping - white is down & black is up???
> On Thu, Feb 24, 2011 at 10:03 PM, Morten Mikkelsen > wrote: > > So as you guys most likely know white means down and black means up when > > bump mapping in Blender > > which is kinda counter intuitive. [SNIP] > > Is there a 'standard' - ie does every other 3d animation package use > the inverse of what we currently use? > > LetterRip My comment about this from IRC summarised: """ As far as I've seen most of the time black means valley/crevice and white means peak when it comes to bump-mapping. See a simple example (orange sphere) here: http://en.wikipedia.org/wiki/Bump_mapping Everything else feels kinda "unnatural". i.e. I myself just can't think of light=valleys & dark=peaks :-D """ That said: I've never seen any application that would assume white=valley. Though I admit that I certainly can not cover a lot of them. If there are any I guess somebody will bring it up :-) Just my 2 euro cent. Cheers, Martin ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Problem compiling under Win32 with scons (SHARD_PATHA in GHOST_SystemPathsWin32.cpp)
> > Thanks for reporting, I overlooked that the define wasn't available for > > mingw. I have added the missing #defines for mingw, so hopefully you > > should be able to compile again. Sorry for the inconvenience. > > Thank you for the fix, I'll check again ASAP (probably tomorrow). I just compiled Blender and it works fine now. Thanks again, Martin ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Problem compiling under Win32 with scons (SHARD_PATHA in GHOST_SystemPathsWin32.cpp)
> Thanks for reporting, I overlooked that the define wasn't available for > mingw. I have added the missing #defines for mingw, so hopefully you > should be able to compile again. Sorry for the inconvenience. > > - Andrea Thank you for the fix, I'll check again ASAP (probably tomorrow). Martin ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Problem compiling under Win32 with scons (SHARD_PATHA in GHOST_SystemPathsWin32.cpp)
I recently got back from a short hiatus from Blender and noticed that I can't compile under Windows/scons anymore. GHOST seems to use a new define (SHARD_PATHA), that doesn't actually seem to be defined anywhere (that I can find). >SNIP> ... ... scons: Building targets ... scons: `source\lib\libbf_intern_audaspace.a' is up to date. scons: `source\lib\libbf_intern_string.a' is up to date. Compiling ==> 'GHOST_SystemPathsWin32.cpp' intern\ghost\intern\GHOST_SystemPathsWin32.cpp: In member function `virtual void GHOST_SystemPathsWin32::addToSystemRecentFiles(const char*) const': intern\ghost\intern\GHOST_SystemPathsWin32.cpp:86: error: `SHARD_PATHA' was not declared in this scope intern\ghost\intern\GHOST_SystemPathsWin32.cpp:86: warning: unused variable 'SHARD_PATHA' scons: *** [source\intern\ghost\intern\GHOST_SystemPathsWin32.o] Error 1 scons: building terminated because of errors. http://projects.blender.org/scm/viewvc.php?view=rev&root=bf-blender&revision=34099 Thanks for any help, Martin ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [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? I'd also like to know about the current status of this code. The few posts/screenshots I've seen are pretty old already, so I'm not sure this was developed further? Cheers, Martin ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
