Images saved with "Save..." menu in Image Window ignored the RGB or RGBA
setting in Scene Output panel.
Also:
- changed menu in "Save As..." to indicate it can change type/name
- added proper info about image in properties panel (RGB, A, Z)
The "generator" class for nodes then better completely disappears, also
from theme color choices menu. Since there was room for it, made the
generator themecolor to become color for 'Convertor' node types.
When through and replaced the obvious ones but there are still a a few Id rather not touch without more about whats going on.
Did quite a few changes to export-iv also.
Export mesh data with modifiers and objects matrix applied. export not only mesh data but text, nurbs etc (thanks to BPYMesh getMeshFromObject)
Small updates to ply import, dont set the TEX of a face (no pink faces anymore)
made ngon loop-reduce function faster by replacing dicts with sets
off_export has some errors, modernized the script.
added a python 2.3 reversed compat function - just uses ls[::-1]
Further 2.3 compat testing needed.
- Jean-Michel Soler (thanks!) pointed that the 3ds importer was missing
license info. Added a GPL license block copied from the 3ds exporter by
the same author.
Report noted the slow icon renders for menus, which indeed is an issue,
especially when texture images need to be loaded (not to mention that
will eat up loads of memory).
Added a flag in scene to disable loading of images, makes it 50 times
faster, at least :)
FTF_GetStringWidth() was calling for translations, whilst translation was
not set even, causing crashes in strings.
Probably this was instable for many cases using Internation Font...
When a curve guide animates, it doesn't correctly work on dynamic particles.
This because the guides work on a fixed starting position (the birth of
particle) and then defines a full path for the entire particle. It is clear
this was only coded with static particles in mind...
Nevertheless, I've added a line of code to at least put the curve guide
on correct location for the moment a particle gets born.
Report moved to the todo tracker; this should be a spec for particle recode
No fix... the Object "TimeOffset" option to work on own ipo doesn't work
at all, not since NaN days. Enabling it is easy, but might screw up a lot
of previous saved files.
I moved that report to the todo, for a make-over of the entire internal
timing system. Added tooltip in button this option doesn't work.
Curves without bevel/extrude don't react to buttons to fill front/back.
That is coded that way, so added this info to the tooltip
Bug report #4566
Creases drawing became very awkward in commit in august last year. Flipped
the drawing order so the fat lines - denoting creases - are drawn first.
That way the value of crease is visible, as well as edge selection state.
Wave Modifier defaulted to Y waves, even when both X and Y buttons were
disabled. That case isn't very useful, nevertheless... if buttons allows it
then it should just work!
Another thread render issue, now in Image texture, the 'repeat' value was
still a global... how did I think that would ever work? Just forgot about
that one I guess. :)
Sequence renders, calling scenes with compositing, didn't execute composite
correctly. Confusement caused by the rule that a "Render" handle has same
name as Scene, which gives conflict for the case when a Scene has
sequencing with Scene strips with its own scene in it.
The previous solution for that conflict caused composite not to work. This
commit solves that, but it is still hackish. Main reason is the still
bad global G.scene, in use by compositor.
LWO cheats by having multiply poly lines in 1, by doubling back on the line. BPyMeshes NGON function splits this into multiple NGons so PolyFill can fill properly.
Tested with 1711 LWO files - (2 had unreadable faces) 77meg and 103 OBJ files- all worked.
Render timers were called in the internal render loops (tile processor),
they still had to be moved to the outer loop, so they include fields/blur
or sequencer render timing correctly.
Thread render error: a flag was stored in read-only data to indicate
whether top or bottom hemisphere of sky was rendered. That can't work
with tiles (but did work when scanlines were threads).
- Assert was causing blender to crash on non-manifold meshes with a decimation
modifier. Even in a debug build, there's no reason to crash blender then,
because the modifier handles this ok and displays a warning message.
Part of the problem is NDEBUG not being set in scons/linux for release builds,
but always enabled for makefiles even in debug builds.
Takes a list of polylines and returns a list of face index triplets.
Added this so using mesh.fill() could be avoided since it requires making an object, linking to the scene and cycling editmode for every NGon imported.
Since this is so close to release, It might be good if ken, willian or stivs takes a look at the function to make sure its ok. - Ran 100's of times for importing lightwave models but would be good to doublecheck.
Added extra security for fill faces. This function is being used for
importing now too, and it gets called for quite weird fill cases...
nevertheless, it should not crash!
AO option "Use Distances" does not work for colored AO, only for "Plain".
I've added this info in tooltip, and added event that resets the color
option for AO when "Use Distances" pressed.
In Editmode armature, the autocomplete for bone names used the bones from
the armature itself, not the edit data.
While fixing, also found out autocomplete for vertexgroup didnt work even.
suffered for the entire movie. :)
It only happened when rendering large frames, using a lot of memory and
typically when you also use other software in meantime.
Reason: the main thread does the drawing updating, while rendering is
still continuing. When using Ztransp, there was a free buffer done
when possibly a draw could still be in progress. Only crashed when drawing
is slow... explaining why it only showed up in more complex cases.
