DerivedMesh implementation of CCGSubSurf. Only used in editmode at
the moment, and does not draw smooth normals correctly.
- Just in its own this brings a rather large speedup for editing
subsurfs.
to determine if element should be drawn and to set draw options),
which meant some could be combined - eases implementation of new
DerivedMesh types and keeps more app specific logic out of DerivedMesh
implementations.
- removed DL_MESH displist type!!!! Now store a DerivedMesh directly.
- May still be some issues left having to do with releasing this
at the right time (old code just splashed free_displist all
over the place).
- switched drawmesh.c to use new functions
- WHEE! This is last such function that has to be written for the time
being, and also effectively marks the end of DL_MESH! DispListMesh still
hangs around as a kind of interchange format but should also die once
DerivedMesh provides more intimate mesh access.
DL_MESH (the displist type for DispListMesh) is still used to hold
the DispListMesh, but that will die as soon as new subsurf switches to
using a bonafide DerivedMesh implementation. There is also one silly
usage for the decimator that is easy to kill.
- Oh, and I also made potatoe mode draw mesh vertex colors - seemed to
be more uniform behavior.
- cancelled previous commit to add RE_findTFAce, instead just added
a MemArena to render struct... free'd at end of render, can be used
to store other data as well
- switch rendering to using DerivedMesh API... this is slightly more
inefficient now because it is doing some unnecessary copying. Can
be fixed by defining a DerivedMesh function to convert the object
into a render object (on todo list)
implementations (slightly redundant, could implement draw in terms
of first... can be cleaned later)
- switch to use of new APIs... all uses of EditVert->ssco are now
clean (read: ready to die as soon as a proper DerivedMesh implementation
is swapped in with ccgsubsurf)
implementations
- updated drawobject selection code to use DerivedMesh (last DispListMesh
usage in drawobject.c that needs to be replaced! Woot!)
- interface could still be a lot cleaner, mostly calculating indices for
the various things to pass to selection color routine is hacky.
this is to ease migration.
- updated particles and STL converter to use DerivedMesh interface. This
is a bit wasteful at the moment, but these are not key performance areas.
Can update once DerivedMesh has accessors for faces and face data.
into drawobject.c (just used for calculating weight
map)
- removed two_sided (replace with glLightModeli calls)
- huge rewrite of drawobject.c for meshes, extracting simple
drawing functions and then reworking to bring some order
and clarity back to the code.
A lot was changed here so it is likely I missed a few
things in testing although I tried to be very careful.
Please let me know if you find any changes in drawing.
Jkey, for showing spare render page, didn't work when using ztransp
material, or buttons F5 open or shaded view.... quite strange eh!
Caused by init-render-material setting R.flag to use Ztransp render.
Globals causing havock yes...
I would like to have proper creasing (following what appears to be
the informal standard in the subdivision surface literature) but
I do not know when I will get to this or how complicated it will
be. With this patch CCGSubSurfs should now have the same capabilities
as regular subsurfs (barring possible bugs) and so replacing the
old implementation is a reasonable possibility.
(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.
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
soon.
- Currently the implementation must be enabled by defining
USE_CCGSUBSURFLIB somewhere with your build system. The code should
be considered highly experimental.
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)
To enable it you will need to download OpenEXR and install it.
For the Makefiles you will need to set WITH_OPENEXR=true
and set NAN_OPENEXR to point to where OpenEXR is installed.
For scons you'll need to remove config.opts to get the new options
so you can enable OpenEXR, I was not able to get blender to link
with scons so the scons stuff may need to be tweaked a little but
I think it should work.
For other platform managers The OpenEXR stuff is similar to QUICKTIME
you need to define WITH_OPENEXR and setup the library stuff and
as you'll notice in this commit there are two extra files.
Kent
It is useful for large scenes, when you work with lot of MetaElems. Example:
http://e-learning.vslib.cz/~hnidek/pics/deer.jpg
(PildaNovak's model)
- shortcuts for hiding of MetaElems:
H ......... hide all selected MetaElems
Shift-H ... hide all unselected MetaElems
Alt-H ..... unhide all hidden MetaElems
- items in header menu of 3dview
Much wanted feature, to have paths with children having fixed distance
offsets from each other, for example to animate a train with wagons.
Solved it with Path option (Editing buttons curve) "PathDist Offs" which
interprets time-offsets of children as blender-unit offsets. The entire
animation system still works, but offsets are calculated based on distance,
even with a CurvePath without motion (speed curve horizontal).
http://download.blender.org/demo/test/pathdist.blend
Thanks to Bassam for kicking my ass!
It used to be a simple hack, scaling lens with 100, and moving the camera
to the back with an equivalent amount.
Because of the hack, making it 100% compatible with older files I could not
achieve (yet?). To help reminding users, I've added a print when reading
old files with Ortho cameras.
Full description of how it works can be found here;
http://www.blender3d.com/cms/Render_changes.515.0.html
Daniel Dunbar
Jiri Hnidek
Ton Roosendaal
Kent Mein
JLuc Peuriere
Kester Maddock
