Re: [Bf-committers] VSE Strip-Wise Rendering
Hi, I have libplugin (http://libplugin.sourceforge.net/intro.html) working in blender. Well, extensions and join-points at least, still haven't ported over the (semi-)current plugin systems to use it. When I say 'working' I mean on linux building with cmake BTW, probably be a chore to get windows going since it brings a couple extra libs into blenderdom. in fact, it doesn't look like the way, a plugin system for blender should work IMHO. We are not aiming at *replacing* core functionality, but providing a clean way, to add certain types of filters / effect tracks etc. And: in comparising to my proposal, it doesn't solve all the interesting things (API version control, symbol dependencies), adds additional complexity through XML files and seems to be centered on Linux. But that's just my first impression, feel free to proof me wrong :) Cheers, Peter Peter Schlaile ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] OpenGL Profiles Project?
Hi Michael, the project is still open, Its normally best for the developers who will review the patch to reply to these mails, Brecht or Ton -. But since they are not, Ill try :). To me its not totally clear what OpenGL profiles would cover, some things come to mind. - Currently we have the GPUGlobal struct which is initialized by GPU_extensions_init, would this be extended to detect more features?, maximum offscreen buffer size for eg? - Make use of more advanced opengl features but allow fallbacks? like FSAA which we have disabled code for... or turning VBO's on if the hardware supports it for eg. - User selectable profiles, allow user to select a profile that draws faster on low end hardware or force a profile if their hardware is not recognized. You also ask about getting help, existing developers can help out with specific issues but first it would be good to see ideas from you as to how you intend to do this. Once you have some proposal its easier to make changes so you can go ahead with the project. On Thu, Sep 30, 2010 at 3:22 PM, Michael Matthews eroberer...@gmail.com wrote: Anyone out there? As I said, this is for a class, and I have a due date for when I need to submit this proposal, and I'd like to know more about what it is before I propose it. =) On Mon, Sep 27, 2010 at 10:00 PM, Michael Matthews eroberer...@gmail.comwrote: Hi all, I am looking for some help on one of the projects that is mentioned on the open projects page. Is anyone willing to give any details on the OpenGL profiles project? This is the description that is given on the projects page: http://www.blender.org/development/current-projects/project-openings/ *develop an abstraction layer for OpenGL Profiles, to wrap specific calls needing exceptions for specific platforms * Is this project still available? Does anybody already have an idea of how to complete that task, and would like to share that knowledge? As for me, I am looking to fulfill a college Masters course open source project requirement, and I would love to do something with Blender. I discussed options on the IRC channel and this project seemed like the best option, but I'm open to other suggestions. Thank you for any help that is available. Cheers, ~MM ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers -- - Campbell ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] VSE Strip-Wise Rendering
On Fri, Oct 1, 2010 at 3:19 AM, Peter Schlaile pe...@schlaile.de wrote:
Hi,
I have libplugin (http://libplugin.sourceforge.net/intro.html) working
in
blender. Well, extensions and join-points at least, still haven't ported
over the (semi-)current plugin systems to use it. When I say 'working' I
mean on linux building with cmake BTW, probably be a chore to get windows
going since it brings a couple extra libs into blenderdom.
in fact, it doesn't look like the way, a plugin system for blender should
work IMHO. We are not aiming at *replacing* core functionality, but
providing a clean way, to add certain types of filters / effect tracks
etc.
It's really just a wrapper around the .so/.dll symbol fetching functions
plus some 'object abstraction' at its core, the libffi stuff is extra icing
on the cake IMO. If someone ever *wanted* to replace built-in stuff (like
the 3dview axis widget in my current tests that someone actually requested
be replaceable) then you can with a simple change in blender's source.
Adding different 'types' of plugins is as simple as filling in a struct and
calling a register function -- they just aren't built in to the core library
since that's most likely application specific and you can have your plugin
types be plugins themselves.
Ideally Blender shouldn't even know or care if the
seq_effect/texture/shader/silly_3dview_widget/etc is compiled in or loaded
from an external lib which is what I'm aiming for with this project.
And: in comparising to my proposal, it doesn't solve all the interesting
things (API version control, symbol dependencies), adds additional
complexity through XML files and seems to be centered on Linux.
You say 'centered on Linux' like that's a bad thing...
It has {application,plugin,libplugin} version control and symbol
dependencies (as I understand them). Admittedly internal version control
needs some love but the basics are there and plugin version control is just
a placeholder at this point IIRC but application version control is simply a
callback function that can do anything you want
Other than libltdl (which is easily replaceable, it didn't start out using
it) the other extra libs (libxml libffi) I believe are already both python
deps.
Anyway you look at it there's going to be extra complexity either through
opening every .so/.dll in a filesystem tree and inspecting the symbols,
executing every python script or parsing every xml file if you want
auto-loading of plugins at startup.
And then you have to come up with a way to keep track of what libs export
what symbols, what libs belong to what plugins, extensions and join-points,
different types (seq, texture, etc) of plugin loading methods, what blender
brings to the table (register functions and whatnot) and wrap is all up in a
python and/or C api.
Sounds like a *lot* of work to me.
Plus there's the recursively importing from the {user,system,comandline}
plugins folder at startup works right now argument.
But that's just my first impression, feel free to proof me wrong :)
I looked at pretty much every plugin system on the internets and this is
the best/most full featured out there that's not a digital sledgehammer. The
guy who wrote this really has his act together, compsci phd and all that.
Pretty sure the original lib is abandoned so I forked it to make it work
with recent libffi, get rid of gcc hash table dependency, the afore
mentioned libltdl changes and did a little refactoring of headers/function
names to avoid 'namespace' clashes...that bug was a bit tricky to track
down.
Currently working on getting the (lame ass) msvc export symbol changes made
so it can work in a non-gcc compiled .exe.
If there are serious objections the xml stuff can be #ifdef'd (which I'll
probably do anyway now that I think about it) and anything that is missing
can be added since the intent is to have this live in /extern as a
semi-independent lib.
Dan
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] VSE Strip-Wise Rendering
On 2010-10-01 23:41, Dan Eicher wrote: On Fri, Oct 1, 2010 at 3:19 AM, Peter Schlaile pe...@schlaile.de wrote: Hi, I have libplugin (http://libplugin.sourceforge.net/intro.html) working in blender. Well, extensions and join-points at least, still haven't ported over the (semi-)current plugin systems to use it. When I say 'working' I mean on linux building with cmake BTW, probably be a chore to get windows going since it brings a couple extra libs into blenderdom. in fact, it doesn't look like the way, a plugin system for blender should work IMHO. We are not aiming at *replacing* core functionality, but providing a clean way, to add certain types of filters / effect tracks etc. It's really just a wrapper around the .so/.dll symbol fetching functions plus some 'object abstraction' at its core, Yes, but it's quite different from what we're trying to do here. Libplugin assumes that the application has extension points where plugins can be added. Each extension point can have, if I understand the docs and illustrations right, *one* plugin; since the function pointer that is the extension point can only point to one place. We need for each extension point to have more than one plugin, and to be able to identify and select between them at runtime. Libplugin has more in common with aspects than plugins. Sorry if I got it wrong. /LS ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] VSE Strip-Wise Rendering
On Fri, Oct 1, 2010 at 3:03 PM, Leo Sutic leo.su...@gmail.com wrote: Libplugin assumes that the application has extension points where plugins can be added. Each extension point can have, if I understand the docs and illustrations right, *one* plugin; since the function pointer that is the extension point can only point to one place. Not really, that's just one of the things it can do. Join-points have a stack that can call the next function down the stack (which can call the next one etc) which could be used to reproduce the imbuf image loading function (try all the image loaders until one succeeds) for example. We need for each extension point to have more than one plugin, and to be able to identify and select between them at runtime. You can get a plugin loaded into a function list like node or operator (or the current plugin system) loading functions pretty easily, just needs a custom loading function. In (evil) xml it would be something like texture symbol=foo where the parser would call the plugin loader function pointer on the texture struct which in this case would probably fetch the symbol 'foo' and register it with blender's texture function. Or something different, whatever you like. The key is that when it sees 'texture' it finds a struct named 'texture' in the list and uses that to parse the xml node so you can hang all sorts of different functionality off the basic library. Like I was saying, the libffi (aspect) stuff is just cowbell... ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] New BGE Actions (Animation) Interface
Hello, Currently the only way to use actions in the BGE is via actuators (FCurve, Shape Action and Action actuators). This leaves Python scripters with clunky solutions to playback animations. To remedy this, the following proposal was created: http://wiki.blender.org/index.php/User:Moguri/BGE_Animation_Proposal I began working away at this, and here is my first patch: http://www.pasteall.org/15953/diff Currently it only supports armature actions, the following play types: ACT_MODE_PLAY, ACT_MODE_LOOP, ACT_MODE_PING_PONG and the following blend types: ACT_BLEND_NONE, ACT_BLEND_MIX The max layers is set to 4, but this can be changed easily. I think shape actions will be easy enough to add (it's deformer based like armatures), but replacing object fcurves might be more tricky as the BGE has it's own IPO system. I'll have to do more digging there. Anyways, my point in sending this to the list is to get feedback from other devs to see if this is heading in the right direction. Another thing is that my main intent for this is better character animation control in the BGE, so I'm not sure if I want to complete all parts of the proposal (eg, logic bricks, all the blend modes, fcurve actuator replacement). I'm willing to work on the getting armature actions working well and possibly shape actions, but I'd also like to get those in trunk. Thoughts? Thanks, Mitchell Stokes (Moguri) ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] OpenGL Profiles Project?
Campball, Thank you, that was helpful. I will be looking into this this weekend to try to come up with a proposal. Obviously if anyone else would like to chime in with more details, and specific proposals that they've thought up for this in the past, that would very helpful, as well! Cheers ~MM On Fri, Oct 1, 2010 at 9:04 AM, Campbell Barton ideasma...@gmail.comwrote: Hi Michael, the project is still open, Its normally best for the developers who will review the patch to reply to these mails, Brecht or Ton -. But since they are not, Ill try :). To me its not totally clear what OpenGL profiles would cover, some things come to mind. - Currently we have the GPUGlobal struct which is initialized by GPU_extensions_init, would this be extended to detect more features?, maximum offscreen buffer size for eg? - Make use of more advanced opengl features but allow fallbacks? like FSAA which we have disabled code for... or turning VBO's on if the hardware supports it for eg. - User selectable profiles, allow user to select a profile that draws faster on low end hardware or force a profile if their hardware is not recognized. You also ask about getting help, existing developers can help out with specific issues but first it would be good to see ideas from you as to how you intend to do this. Once you have some proposal its easier to make changes so you can go ahead with the project. On Thu, Sep 30, 2010 at 3:22 PM, Michael Matthews eroberer...@gmail.com wrote: Anyone out there? As I said, this is for a class, and I have a due date for when I need to submit this proposal, and I'd like to know more about what it is before I propose it. =) On Mon, Sep 27, 2010 at 10:00 PM, Michael Matthews eroberer...@gmail.comwrote: Hi all, I am looking for some help on one of the projects that is mentioned on the open projects page. Is anyone willing to give any details on the OpenGL profiles project? This is the description that is given on the projects page: http://www.blender.org/development/current-projects/project-openings/ *develop an abstraction layer for OpenGL Profiles, to wrap specific calls needing exceptions for specific platforms * Is this project still available? Does anybody already have an idea of how to complete that task, and would like to share that knowledge? As for me, I am looking to fulfill a college Masters course open source project requirement, and I would love to do something with Blender. I discussed options on the IRC channel and this project seemed like the best option, but I'm open to other suggestions. Thank you for any help that is available. Cheers, ~MM ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers -- - Campbell ___ 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
