bf-blender / Windows (2005/03/20) updated

User-contributed CVS development builds. Please test and give feedback!

Moderators: jesterKing, stiv

Posts: 0
Joined: Thu Jan 15, 2004 6:41 am
Location: Canada - Québec - Sherbrooke

bf-blender / Windows (2005/03/20) updated

Post by gabio »

Wow. developement got a big boom in the last few days. Enough for me to do 2 builds in 2 days.

update: new interesting stuff again. Also take note you need to reinstall the .blender dir if you wasn't, important change made.

For more info on new tranform: ... efactoring
Done with MSVC 7 and scons!
Relevant feature:
-Revive: Individual Element (object) center for Rotate and Resize
-python: patch submitted by guitargeek(texte3D module) include new stuff.
-Added new script menu entries
-Updated menu registration so that scripts folders can become trees
-Transform widgets; Scale and Rotate versions
-python: Added Blender.Run(script) + doc update
-New Bpy Object method: insertIpoKey()
-New Material method: insertIpoKey( key_type )
-Initial integration of CCGSubSurf library into blender.
-Scripts (making some changes to the scripts dir)
-widget UI tweak:
--added 'ghosting' for while using translate/scaling widget
--added 'pie chart' ghost to denote angle while using rotate widget
--added settings to tweak widget in User menu (InfoWindow) "View & Control"
--Size: total widget size as percentage of window size
--Handle: as percentage of widget radius
--Hotspot: for clicking handles, in pixels
--Fized Size: option to make Widget size independent of window size
-widget: now support for global/local/normal orientation.

Individual Element (object) center for Rotate and Resize. Note that using this in edit mode is a bit useless right now, but we have some surprises in our bozo bin :P

Transform can switch mode on the fly again (GRS).

Fixed a bug with the BIF constraint call, needed to call startConstraint and normalise the space matrix (this affected the manipulator).

- patch submitted by guitargeek
*Text3d accessors - ablity to manipulate FONT objects through python
*update to - calls text_to_curve upon ob_font link for drawing
*update to constant.h - constant type checking define
*update to curve.c - clamp values on getters/setters
*clean up of Text3d module


- Scripts:
fixed error in "Save Current Theme" which prevented it from automatically updating script registration in menus.
cosmetic changes in a couple of Campbell's script strings + more descriptive name for its new menu place (3d view, face mode -> select menu).
small updates to script.

The above changes are related to this:
- Added new script menu entries: Render (for exporters to renderers), Themes, FaceSelect (this already at the proper place). Updated Scripts win->Scripts menu so it won't show all available entries, only the ones we mean to see there.
- Updated menu registration so that scripts folders can become trees. The release/scripts/ dir should be updated soon with subdirs like converters/, modifiers/, generators/ or whatever -- better discuss first (or is it? /me afraid of long irc discussions during meetings :) ).

- Modules:
Blender: added 'udatadir' option to .Get() function and added var Blender.mode to tell if Blender is in bg or interactive mode.
NMesh: added Campbell's nmesh.transform(matrix, recalc_normals = False) method (reworked, so my fault if it doesn't work).

- Bugs fixed:
#2123: ... group_id=9
Reported by Ken Hughes (thanks!), who also found the exact problem later (it was in Text.Load, not with script links -- if only I had checked emails these days ... lost > 1 hour today to find the problem: passed filename to M_Text_Load was later being written over by a function called by add_text). Also saw that Text.Load wasn't checking existence of passed filename (duh!), now it does.

#1655: ... group_id=9
Reported by Chris Want (thanks!): command line "blender -P script" not working properly for bg mode ("blender -b blendfile -P script").
Had to make some small updates to get it working (bg mode for scripts was never explicitely handled, it worked due to collateral effects, let's say), interested readers can check the report after I update it or the doc file. After more testing we can make further updates. Updated many places to not call redraws if in bg mode, now it is officially available. Blender outputs its own info when rendering in bg mode, if that is considered a nuissance we'll have to add a few "if (during_script())" calls outside bpython.

- Removed a few warnings here and there and also updated docs.

Transform widgets; Scale and Rotate versions

To use; press the (temporal) icon in header. Switching widget types is by
pressing G, R or S once, if current widget type is different it switches,
otherwise it goes to normal Transform().

Widgets need a bit test for picking accuracy, correct drawing etc.
The rotate widget has a center button for 'trackball' rotate. That latter
can also be used for hotkey-based rotate.

In current code, all widgets remain in "Global" space, also in editmode.
Also widget updates while using normal transform has to be done.

2 Bugfixes:
- rotate in PoseMode had error for 2d 'around' center
- transform in postemode could crash, due to typo (& or |)

- Added Blender.Run(script) + doc update (forgot to mention in my previous commit).

Trying to fix two mistakes from my previous commit:

- nmesh.transform(): forgot yesterday that affine vectors have 4th component = 0, now updated normals transformation accordingly.

- As Ton pointed, recursive parsing of scripts dirs in search of scripts was a mess. I simply forgot about the "//" trick and much worse, to protect against worst cases ("/", for example). Now the code uses BLI_convertstringcode to take care of "//", doesn't process if dir = "/" and there are limits:

max depth for traversing subdirs = 4
max dirs in the tree = 30.

I'll work more on this, check more, but these changes were tested and should make the code safer, of course, so I'm committing. Sorry about the mess, I should take lessons on defensive programming ...

New version of rotate handlers. I like it! Now the rest of you ;)

Little fix; while Transform() in editmode, and other objects were select,
these objects were drawn in transform color (white usually)

Some cleaning up of BLI_winstuff.h usage
- removed reference in render.h (really bad, shouldn't include a platform
specific header so widely unless really necessary)
- added M_PI, M_PI_2, M_SQRT, M_SQRT_2 defines to BLI_arithb.h... this is
a better place as it is more the "standard" blender math header. left
in winstuff.h as well for the moment for simplicity
- other changes are patches to code so everything works ok with this

Global G.moving got nice define flags, and additional meaning.

- move object mode
- move editmode/pose mode
- move with widgets

- add some windows specific defines to BIF_gl.h so that OpenGL can
be used without including windows.h - this is the main reason windows.h
is included in so many places and this change allows most of those
inclusions to die.

- remove all obsolete inclusions of BLI_winstuff.h (due to recent changes)

NOTE: BLI_winstuff.h was meant to be a wrapper around windows.h to handle
undefining various crap that windows.h defines. Platform specific headers
should only have to be included in a few places. This reduces the number
of inclusions of BLI_winstuff.h to 16 which is a much more reasonable
number (than the 144 or whatever it used to be)

Log: (python)
fix warning: initialization makes integer from pointer without a cast

- added helper lines in rotation widget
- switched to Local mode for widgets by default, will be a key/button later

New Bpy Object method: insertIpoKey()
inserts Object IPO key for LOC, ROT, SIZE, LOCROT, or LOCROTSIZE
Contributed by Johnny Matthews (guitarGeek)

Ton broke a couple of things in his last commit including PET in rotation mode and local axis constraints on objects.
Bringing that back and enabling PET in trackball rotate.

Changed the rotation manipulator drawing code to really align the Trackball rotate ball with the view (using getViewVector) so that it always looks centered on the selection.
This was particularly ugly in perspective mode with a selection far from the center of the screen:

Moved getViewVector from transform_constraints.c to transform_generics.c since it is not really a constraint related function. Also made it independant on the TransInfo structure so it might be useful elsewhere too.

Adding some docs for Text3d additions

Adding some docs for Object insertIpoKey additions

- Fixed flipped orientation of getViewViewvector(), was opposite in ortho
versus perspective.
Note for Martin; still an issue with defining what positive/negative
rotation is in perspective... needs more math here!
- Added Transform Widgets for PoseMode
- made adding bones in EditMode setting G.moving, so it doesn't draw other
selected objects nor Widgets

Warning in commit of Martin yesterday: Trackball and initTrackball were
declared static, whilst also in transform.h. Quez; why are these functions
exported in the .h file?

correct bad reference to getDrawMode.

Three rotate manipulators to play with;

G.rt = 0: one handle for each rotate axis
G.rt = 2: traditional half-circle rotate handles
G.rt = 3: mixed version
(rt is the general debug var in render button, just under "render sequence")

New Material method: insertIpoKey( key_type )
inserts material ipo key at current frame.
contributed by Johnny Matthews.

Adding some docs for material insertIpoKey additions

- apologies, accidentally commited code w/ game engine disabled

- kill some warnings (open/seek/read/write need io.h on win32)

Warp was acting weird if the cursor wasn't centered in the data space, that is fixed.
Helpline for warp was wrong in edit mode if the object wasn't centered on global space.
Boundbox calculation for warp is done in view space now, so it is always maximised since aligned with the view.

Switch the negative/positive switch for Shrink/Fatten from horizontal motion to vertical motion. Pull down to shrink, pull up to fatten. This could still use some work.

BugFix: Constraint center was wrong with MMB (was bypassing the fix I commited the other day).
BugFix: Changing modes while in transform and switching to local constraints in edit mode crashed. This was due to resetting the TransInfo flag in initTransModeFlags. Now done correctly in initTrans.

- Initial integration of CCGSubSurf library into blender. The lib is
only in one C file and not worth dropping in extern but presumably
will be synced with public CCGSubSurf release I hope to be making
- Currently the implementation must be enabled by defining
USE_CCGSUBSURFLIB somewhere with your build system. The code should
be considered highly experimental.

- Part of CCGSubSurf integration, this is the actual blender side of the

- remove some duplicate prototypes, causes problems for some compilers
- update new conversion to DLM routine to use match subsurf
(means optim, seams, selection should work same now, but I am
not super familiar with all this stuff so can't test very well).

These hacks to the DLM structure are disgusting btw Ton. What
a waste of memory! All the information that is so meticulous to
kept and managed in the old structure is essentially explicit (or
easily made so) in the new one.

Scripts (making some changes to the scripts dir):
- moved bpydata/ to scripts/bpydata/ and added a config/ subdir to it;
- created scripts/bpymodules for py modules (also got rid of those "mod_"'s appended to the files);
- updated scripts accordingly.

This will require you to "reinstall" (just copy the scripts/ dir over your older one) if you have a .blender/scripts/ dir somewhere. Otherwise some scripts won't work. You can use the updated "Help->System->System Information" script here to check all is fine. An installer script yet to be written will help users with these issues, specially to make the user defined dir have the same structure expected from the default scripts dir, so the basic facilities (module search; saved config data; scripts: installer, help browser, config editor) are also available for a user's own collection of written and downloaded scripts.

- slikdigit's crash was because he had no <home or blender exe location>/.blender/:
proper check added and also now if all else fails the <cvsblender>/release/scripts/ dir is also searched for scripts. All this registration dirs stuff is a little messy (installation!), so please report any troubles (I only tested on linux).
- slight change in error report in BPY_interface.c's BPY_menu_do_python; remembering to set globaldict pointer to NULL there, too.
- moved bpy_gethome() to EXPP_interface.[ch]
- "//" as user defined python dir is ignored while looking for scripts, considering it's only a default some users use, not really meant for a scripts dir.

More transform widget goodies;

- added 'ghosting' for while using translate/scaling widget
- added 'pie chart' ghost to denote angle while using rotate widget
- added settings to tweak widget in User menu (InfoWindow) "View & Control"
- Size: total widget size as percentage of window size
- Handle: as percentage of widget radius
- Hotspot: for clicking handles, in pixels
- Fized Size: option to make Widget size independent of window size
Not sure if all of these are useful to keep, but makes for good testing
in this stage.

Also: made #define to use new transform to be set TRUE by default now. *sheer* :)


- cleaner code for selection of handles in transform widget. in ortho views
selecting the center handle defaults, to prevent Inf. overflows for
perpendicular handles. While holding SHIFT it works the opposite!

- removed redraws on modifier (CTRL, SHIFT) key release. that ensures you
can apply to grid nicely (functioned that way in all blender releases)

Shrink/Fatten behavior change. This time for good I hope.

Technically, it now works by getting the mouse motion in 3D (just like Translation/Grab), projecting it on the vertical view axis, using the vector length as the shrink/fatten factor. If the motion is downward (on the screen), shrink, if it is upward, fatten.
In layman terms: move up to fatten, down to shrink and it adapts to the viewport zoom, like Translation.

I changed to snapgrid factors to match those of Translation to, so it really acts like grabbing.

Added string to BIF_setSingleAxisConstraint() function for headerprint.
Needed for martin to further work on print stuff

Created initConstraint. It basicly just checks if the CON_APPLY has been set up (by the BIF_setConstraint calls for example) and calls startConstraint. This must be done because startConstraint uses data initialised when starting transform so it needs to be called after that.
Also changed some strcpy into strncpy.

Fix for possible divide by zero error in Rotate.

Fix for MMB behavior when two axis were exactly on one another or very close. It now defaults like this: X, Y, Z (meaning if as near as X as Y, it chooses X). This could be fixed further.

Size flipping, for kaito. Move pointer to the other side (horizontal) of the pointer to see. (Does affects size member, so just object position and edit mode)

Transform widget update

- now support for global/local/normal orientation.
- LMB click on center switches orientation mode
- in object mode, local (now) only displays on single object selected
- in editmode, Normal orientation is derived from faces selected
- if no normal can be found, it shows local orientation

Currently implemented, for test, in Mesh editmode and PoseMode.

Note for PoseMode; the 'translation widget' shows on "IK" bones but
doesn't translate, it rotates instead. Pretty interesting to use the
translate widget for it...least cluttered display I think.

Note for Matt; I tried MMB click for switching orientation... it's just
weird that way... such clicks, repeatedly, with mousewheels isnt nice
a new build is available
Last edited by gabio on Wed Mar 23, 2005 11:40 pm, edited 4 times in total.

Posts: 110
Joined: Wed Oct 16, 2002 6:52 am

Post by Saluk »

Still no lights in the game engine. Did someone comment them out somewhere?

Posts: 4
Joined: Thu Oct 17, 2002 9:39 pm

Post by Zsolt »

Great, thanks! The widgets are getting beter and better. I find myself using the grab widget in editmode all the time for quickly moving the vertices in one direction, especially useful for small 'nudges'.
About the rotating widgets:
Type 0: Good, easy to visualise the "handles".
Type 2: This one is also good, in that you can see the plane of the rotation, probably the one giving the most visual feedback.
Type 3: looks very confusing, easy to mix up the directions.

Personally, I'd prefer a type mixing 0 and 2, with the same handles as 0, plus a thin circle to visualise the plane of rotation, same as type 2, but thinner.
If I had to choose from the existing ones, then type2! Sometimes the handles of type 0 are rotated so that you can't tell wheter they are in front of, or behind an object, which means you can't tell which way it will rotate if you move it.

It would also be helpful to have a button in the header for switching the coordinate systems used (local/global), but I hear Ton is working on that.

Another thing: this has been in the previous several builds as well. If the grid in View properties is set to a small value, like 0.01, when I zoom in, the grid lines in the 3DView jump around the place, and don't stay where they should.
Using: WinXP with SP2, Athlon64 2800+, Ati Radeon 9600 Pro.

Posts: 15
Joined: Thu Oct 17, 2002 10:20 am
Location: Berlin, Germany

Post by thoro »

Wow, the widgets are really good, especially to flatten Blender's learning curve. I prefer rotating widget Type 0, and I like Zsolt's idea of a thin circle to visualise the plane of rotation.

I saw that it's still not possible to rotate around local axes in Armature Posing Mode. I guess that's because the new transformation system is in development, right?

I also like the new Proportional Editing modes.

Posts: 86
Joined: Fri Oct 18, 2002 2:47 am

Post by solmax »

ha - great! all thumbs up for the widgets. they work perfect.


Posts: 0
Joined: Sat Sep 04, 2004 2:32 pm

Post by kakapo »

the widgets are nice!

some feedback:

translate widget -> not only the tips should be pickable but also at least half of the axis. this could make it easier to pick in some cases?

rotate widget -> i prefer mode 2 but i like the visual feedback (the line to the center) of mode 0 during rotation.

Posts: 0
Joined: Mon Jan 05, 2004 9:25 pm

Post by bullx »

wow thank you.
my vote to rotation 0

rotation 1 is sexy but a little bit less "friendly"

rotation 3 "mixed mode" isn so good as others.


Posts: 96
Joined: Fri Jan 10, 2003 6:41 pm

Post by joeri »

Nice widgets.

I have swap buffer problems when using widgets.
Maya used pad+ and pad- to scale the widgets, idea?

Why does the whiteball move in rotation mode?

another tip, draw a pie in the rotation widget from old to new position. (or a gray line on old position)

Cones are nice, not to happy with the bulky sphere. why not a cube like in scale?
Zbuffer on widget does not seem to work, is this on purpose? This can get confusing. If an arrow is pointing away from me but draw over the white center.

Posts: 11
Joined: Wed Oct 16, 2002 4:09 am
Location: New York

Post by kirpre »

Couple of questions, as this is the first time I have tried using the widgets:

1) It seems that holding SHIFT to move in small increments while using the widgets only works with Rotation, it doesn't seem to work with scale or move. Is this on purpose or is this just still WIP.

2) How do you switch between the differnet widgets that are being tried for the rotation?

Posts: 0
Joined: Wed Jan 21, 2004 3:27 pm

Post by Bellorum »

Ooh! Ton's working hard right now:)

Todays log:
More transform widget goodies;

- added 'ghosting' for while using translate/scaling widget
- added 'pie chart' ghost to denote angle while using rotate widget
- added settings to tweak widget in User menu (InfoWindow) "View & Control"
- Size: total widget size as percentage of window size
- Handle: as percentage of widget radius
- Hotspot: for clicking handles, in pixels
- Fized Size: option to make Widget size independent of window size
Not sure if all of these are useful to keep, but makes for good testing
in this stage.
That sounds great:)
There's no such thing as democracy. There's only the tyranny of one, and the tyranny of many.

Posts: 0
Joined: Sat Jan 24, 2004 4:12 pm

Post by JoOngle »

Really cool update! Thanks a bunch - testing like crazy now.

Note: Widgets would "really" be useful if they also had some sort
of real-time distance measurement + angle value that shows while
transforming. Later one could add "snap-to-point-values" to set rules!
This would increase live-modelling accuracy.

Something good: I **really** like that transform widgets are sticky!
Sticky to each viewport - left the way it was last used! Love it!
Please keep it like that, that is quite good for the workflow.


Posts: 0
Joined: Sun Apr 11, 2004 4:57 am

Post by ZanQdo »

Yes, the widgets opens the posibility to many usefull snapping methods, devs should check Its a simple arquitectural modelling program that have brilliant rotation and snaping tools, this with the new HEMesh that supports ngons an a OpenCSG boulean sistem would be a dream for modelling buildings, machines, all kind of non organic models (I think blender is the best organic modeler right now) :D :P

Im so happy that I know Blender :)

Posts: 41
Joined: Wed Oct 16, 2002 1:16 am

Post by Doogs »

Any realtime lighting is suddenly disabled in this build. Not sure why. Just thought youd like to know

Ron Cavagnaro

Posts: 0
Joined: Thu Mar 04, 2004 1:28 pm

Post by SamAdam »

everything works great with the widgets.

i prefer 0, maybe with an angle filler like maya (shudder, unfortunately maya is quite good at this right now, so we can copy shamelessly.)

why is only rotate have the view dependent transform? grab could have this also.

i also realize that this will invalidate all tutorials from before now.

would it be possible to make the size of the gizmo constant rather than a percent of the view area? if I have four 3d views the gizmos are too small to use.

Posts: 0
Joined: Sat Jan 24, 2004 4:12 pm

Post by JoOngle »

SamAdam wrote:
maya is quite good at this right now, so we can copy shamelessly.)
No - thats very dangerous! We can make SIMILAR features, but
copy shamelessly we can´t - especially with the european
software-patents just around the corner.

It will be possible to patent everything from a formula to a
certain way of storing files - a widget will also be counted as a
patent if a company holds a patent on a certain behaviour, so
we better document everything carefully and make sure we´re
not doing the very same thing as the "competing commercial brands".

I´m saying this because I´m in "love" with Blender - literally!
It´d be a catastrophy if Blender in a future "drama" got caugth
in a battle for survival against one of the biggies (who shall remain
nameless) that feels that Blender is becoming a valid treath (competitor)
to it´s products.

This - WILL - happen, it's just a matter of time when enough serious
companies are using Blender (and they DO - eventually, I´m one
of them) I just want to ensure that the worst-case scenario never
takes place!

Post Reply