Re: [Bf-committers] Reference counting, deleting data and fake users
Would it be difficult to add a mode of saving which would not drop the unreferenced data? This would allow the user to decide when the garbage collection is done so you'd know when you have to worry about things going missing. Additionally a way to list data to be deleted might be nice. 16. maaliskuuta 2012 18.43 Alexander Zubov a_zubo...@yahoo.com kirjoitti: I think the easiest solution to this issue would be adding a prompt message on exit You have unsaved Actions. Would you like exit anyway? or something on that nature. This way user can go back and press F button on the Actions he wants to keep. --- On Fri, 3/16/12, Bassam Kurdali bas...@urchn.org wrote: From: Bassam Kurdali bas...@urchn.org Subject: Re: [Bf-committers] Reference counting, deleting data and fake users To: bf-blender developers bf-committers@blender.org Date: Friday, March 16, 2012, 11:21 AM big -1 I don't think it's simple, and I'm not sure it's even desirable; changing behavior like this, when the original complaint was that actions not getting fake users by default, going into a massive change of design. there are so many things in blender that need big redesign, like the dependency graph and library linking/refrencing, that going into major restructuring of things that *aren't broken* just seem like a ridiculous thing. Especially as this would be at least a highly controversial change. So if you're looking at a big architectural/ design/ under the hood challenge, wouldn't you please fix the depgraph first ;) ? I don't see any big technical difficulty personally. We can just modify the refcount increasing/decreasing function to use an observer pattern scheme and if a datablock is deleted simply inform the observers of the deletion (And the human user if the datablock has more users). It will require some interface for the observers too but I don't think it's an unsurpassable challenge, even in C :p. The memory footprint of datablocks will slightly increase but it's a negligible amount of data compared to meshes etc. ___ 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 ___ 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
Re: [Bf-committers] Collada-patch for testing
Hi, I put the export part of the patchhttp://projects.blender.org/tracker/index.php?func=detailaid=30050group_id=9atid=127I made in the tracker, some small additions I think which weren't in the previous version. This is in line with things I can mostly help with, I added some remarks about what compatibility issues imo can be with importing though of course these depend on the use case. 2012/2/1 Domino Marama dom...@dominodesigns.info On 02/01/2012 10:33 AM, Ton Roosendaal wrote: Hi, Let's wait a bit with a new list; we can do that when this project is really being tackled actively and everyone here's getting bored of collada discussions :) Fair enough. There's the opencollada implementation and at least 3 partial python based exporters - I just thought that discussion of the relative pros and cons of those may result in fairly heavy traffic for awhile. It's the outcome of those discussions that I'd expect to form into a plan that would go onto the wiki. You're for sure very welcome to join irc.freenode.net #blendercoders. There's always 100-150 people hanging out. I'd love to figure out what you can do precisely, or where your interest is mostly. I've arranged to set aside part of the income from sales of our Second Life addon scripts (Avastar and Primstar) to fund my work on Collada. Collada is an essential feature for Second Life both for Blender users and for users of other applications such as Maya and ZBrush who use Blender to convert their content to Second Life via our scripts. We've also users who model in Blender, and take content out to ZBrush for detailing. so a solid Collada implementation for both import and export is a priority for us. The funding I have will cover at least four hours a week spent on Collada issues, so my medium term goal would be to become the maintainer for the Collada features in Blender. Short term goal is to get up to speed with the code base by fixing a few bugs.. Best Wishes, Domino ___ 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
Re: [Bf-committers] Collada-patch for testing
Hi, Gaia Good to hear it does something right:) In response: 1.) Does it work ok with maya without the Second Life- box checked? There are some other changes to export which may also affect results. 2. and 3.) The export with compatibility mode is probably the same as 2.49b. I still need to do some research on that with different software to have a better understanding, but in the end it's a cosmetic/UI issue which is the preferred mode if it comes to that. 4.) The imported bones should come out as the regular rig unless your pipeline is modifying the armature somehow? Adding bones for example would mess with reinterpreting the bones as lines between joints. I'll probably separate the patch into two parts since the exporting code is more straightforward and the compatibility part can be controlled from the UI so it should have a better change of making it in. The importer part is bit more involved, have to see about it. 2012/1/30 Gaia Clary gaia.cl...@machinimatrix.org Hi, kanttori; Your patch works fine for export. For import see remark 4.) below. I first had some issues but it turned out that i made a mistake when i disabled our workaround code for the current Collada exporter. After i fixed our tools and removed all these (ugly) workarounds all is well now. Some remarks which may be of common interest regarding this patch: 1.) The exported .dae files from your patch also seem to be importing well into Maya while the current .dae exports from official Blender Collada fail miserably on Maya. 2.) Your patch seems to make Blender trunk compatible with Blender-2.49b We never had issues with .dae exported from 2.49b (neither for Maya nor for Second Life) 3.) Therefore i also believe that the explicit mentioning of Second Life in various places in the patch is not necessary , because i believe it is not a patch to make Collada compatible to Second Life, but a major fix of something where possibly Collada standards do not tell explicitly how the export has to be done and Blender does it maybe correct but in a not so lucky way. 4.) Blender itself can now import its own .dae files which seems to be a major improvement, but a first inspection shows that the bones are rotated by 90 degrees after import, which results in exactly(!) the same rig that we used as workaround for getting exports to work with the current Collada exporter ;) Thanks for that great step towards a better Collada world :) cheers, Gaia Am 29.01.2012 20:31, schrieb Juha Mäki-Kanto: Hi, I've been looking into collada, mainly from the transforms-side of things (since I know more about them then collada). Here's a patch in pasteallhttp://www.pasteall.org/28655/diffand brief synopsishttp://www.pasteall.org/28656/text. Would like to know if it fixes export to second life (via compatibility check box in the export dialog) and if this then works with animation exported from blender which afaik is BVH. Should also fix #29246 and #29082 which are import-problems of animation and armature. ___ 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 ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Collada-patch for testing
Hi, I've been looking into collada, mainly from the transforms-side of things (since I know more about them then collada). Here's a patch in pasteallhttp://www.pasteall.org/28655/diffand brief synopsis http://www.pasteall.org/28656/text. Would like to know if it fixes export to second life (via compatibility check box in the export dialog) and if this then works with animation exported from blender which afaik is BVH. Should also fix #29246 and #29082 which are import-problems of animation and armature. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Collada importer/exporter kickout
That being said, would be helpful if someone could give a concrete example of how the exporter-side fails when skinning (not bones look different after collada * ) or the error in my logic. From looking at the files produced the animation matrices should be correctly parent space. * Bones may look different after import/export if they are interpreted as lines between joints (where a leaf-bone doesn't have a well defined orientation) or bones just are on different axis. 2012/1/14 Juha Mäki-Kanto kiskos...@gmail.com Hi, Did some digging into this - armature animation vs colladahttp://www.pasteall.org/28205/text From testing and looking at the code Blender imports and uses animation curves directly which isn't good. It'll only match the original in special circumstances like if the rotation difference between bone's restpose vs parent's restpose is identity and you're only animating rotations. For Second Life there is actually a trick to set all restbones to be positive Y-axis (identity matrix) which apparently then loads correctly there. It seems that 2.59 did export/import for armatures correctly (#29082http://projects.blender.org/tracker/?group_id=9atid=498func=detailaid=29082); tested it and the eulers in the file were interpreted to be quaternions (and the animation works) so the previous system was somewhat aware of this caveat. The gist to me is that collada's transformations may not match a program's internal representation and reinterpreting usually goes via collada data to full matrix, possibly fix the matrix and then decomposite to curves. It's a lossy conversion, key's should match but interpolation won't - you need to bake/key every frame when importing the curves. 2012/1/11 Sebastian sebast...@opencollada.org Is there a list containing all COLLADA related bugs somewhere? There are only a few, some of them very unspecific, on the 2.6 bug tracker. On 11.01.2012 11:06, Ton Roosendaal wrote: Hi, You can count on plenty of people jumping on a patch if you publish it. Don't understimate the power of having many eyes looking. If it requires more expertise or IO experience, Campbell is around to check on it too. -Ton- Ton Roosendaal Blender Foundation t...@blender.orgwww.blender.org Blender Institute Entrepotdok 57A 1018AD Amsterdam The Netherlands On 10 Jan, 2012, at 23:39, Juan Linietsky wrote: Heh I wanted to emphasize that it works, but I seriously do need to work with someone familiar with writing blender and/or blender import plugins in C++ to do it, who can take my code and adapt it to Blender. It should be a short task for someone with that experience. Cheers Juan On Tue, Jan 10, 2012 at 6:53 PM, Daniel Salazar - 3Developer.com zan...@gmail.com wrote: That sounds *very* exciting and *very* appropriate for our needs :) OC ads too much weight to Blender's big ass Daniel Salazar 3Developer.com On Tue, Jan 10, 2012 at 3:48 PM, Juan Linietskyredu...@gmail.com wrote: I didn't realize a collada exporter was so important. If so.. I have a *very* *tested* and *very* *small* collada importer in my middleware stuff (~3k lines of C++ code). It supports pretty much everything (models, skeletons, materials, cameras, lights, morphs, any-axis orientation, animations with matrices or curves, etc). Given it's very small size and non-dependency on OC, it's very easy to understand and *very easy to mantain*. It pretty much just ignores conformance of input files and just attempts to grab wathever data it needs so *compatibility is extremely high*. It's not a standalone library, but it's separated enough that *if someone knowledgable of blender internals *wants to give a try to adapting it to blender (of course with me 100% available for answering questions with this), i think in a matter of a few hours we can solve the Blender problem of collada import support. However as I said in previous mails, I really lack the time to get familiar with Blender internals and do this myself. Cheers Juan Linietsky On Tue, Jan 10, 2012 at 11:30 AM, Erwin Coumans erwin.coum...@gmail.com wrote: Until Blender has good fbx import or an alternative collada import (python?) it would be good to postpone dropping OpenCollada. From the feedback, some people are using the import feature, and there is no replacement. Let's hope someone stands up and fixes the issues in trunk, rather then branch. On Jan 10, 2012 2:15 AM, Ton Roosendaalt...@blender.org wrote: Hi, The Collada conformance suite is not working, and working on it won't help anything. I wrote about this here; http://code.blender.org/index.php/2011/10/collada-momentum/ Collada just has no reference stakeholder(s) (like how fbx was native for motionbuilder). Blender
Re: [Bf-committers] Collada importer/exporter kickout
My basic point is that to me it seems like going to collada means you either haven't done object/armature animation yet or you're done with it and happy to have it baked as per frame rot/loc/scale or matrices. I'm not sure about most other programs so I'll just ask: what would be the correct way in collada to handle a parent inverse- matrix in child-objects (possibly has skew in it) and the default rest-pose attributed translation+rotation between parent-child bones? 2012/1/15 Juan Linietsky redu...@gmail.com The problem with importing/exporting of Collada and skeletons is not really that it doesn't match the internal representation. Animating 3D objects in a 3D Animation package is always done through euler angles, local or global, and that is easy to export seamlessly in Collada. But skeleton based models like characters almost always use IK or other sort of constraints which are impossible to convert back to euler due to gimbal lock issues, so the only way to reliably export skeletal animation is to export a full rotation snapshot either via a quaternion (which Collada does not support) or 4x3 matrix., and later optimize redundant keyframes to save storage space. So I think in short, it's the lack of support for constraints what makes Collada not very useful as an exchange format between DCCs, but yet it's still very useful for exporting to game engines. Juan On Sat, Jan 14, 2012 at 5:28 PM, Juha Mäki-Kanto kiskos...@gmail.com wrote: The gist to me is that collada's transformations may not match a program's internal representation and reinterpreting usually goes via collada data to full matrix, possibly fix the matrix and then decomposite to curves. It's a lossy conversion, key's should match but interpolation won't - you need to bake/key every frame when importing the curves. ___ 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
Re: [Bf-committers] Collada importer/exporter kickout
Hi, Did some digging into this - armature animation vs colladahttp://www.pasteall.org/28205/text From testing and looking at the code Blender imports and uses animation curves directly which isn't good. It'll only match the original in special circumstances like if the rotation difference between bone's restpose vs parent's restpose is identity and you're only animating rotations. For Second Life there is actually a trick to set all restbones to be positive Y-axis (identity matrix) which apparently then loads correctly there. It seems that 2.59 did export/import for armatures correctly (#29082http://projects.blender.org/tracker/?group_id=9atid=498func=detailaid=29082); tested it and the eulers in the file were interpreted to be quaternions (and the animation works) so the previous system was somewhat aware of this caveat. The gist to me is that collada's transformations may not match a program's internal representation and reinterpreting usually goes via collada data to full matrix, possibly fix the matrix and then decomposite to curves. It's a lossy conversion, key's should match but interpolation won't - you need to bake/key every frame when importing the curves. 2012/1/11 Sebastian sebast...@opencollada.org Is there a list containing all COLLADA related bugs somewhere? There are only a few, some of them very unspecific, on the 2.6 bug tracker. On 11.01.2012 11:06, Ton Roosendaal wrote: Hi, You can count on plenty of people jumping on a patch if you publish it. Don't understimate the power of having many eyes looking. If it requires more expertise or IO experience, Campbell is around to check on it too. -Ton- Ton Roosendaal Blender Foundation t...@blender.orgwww.blender.org Blender Institute Entrepotdok 57A 1018AD Amsterdam The Netherlands On 10 Jan, 2012, at 23:39, Juan Linietsky wrote: Heh I wanted to emphasize that it works, but I seriously do need to work with someone familiar with writing blender and/or blender import plugins in C++ to do it, who can take my code and adapt it to Blender. It should be a short task for someone with that experience. Cheers Juan On Tue, Jan 10, 2012 at 6:53 PM, Daniel Salazar - 3Developer.com zan...@gmail.com wrote: That sounds *very* exciting and *very* appropriate for our needs :) OC ads too much weight to Blender's big ass Daniel Salazar 3Developer.com On Tue, Jan 10, 2012 at 3:48 PM, Juan Linietskyredu...@gmail.com wrote: I didn't realize a collada exporter was so important. If so.. I have a *very* *tested* and *very* *small* collada importer in my middleware stuff (~3k lines of C++ code). It supports pretty much everything (models, skeletons, materials, cameras, lights, morphs, any-axis orientation, animations with matrices or curves, etc). Given it's very small size and non-dependency on OC, it's very easy to understand and *very easy to mantain*. It pretty much just ignores conformance of input files and just attempts to grab wathever data it needs so *compatibility is extremely high*. It's not a standalone library, but it's separated enough that *if someone knowledgable of blender internals *wants to give a try to adapting it to blender (of course with me 100% available for answering questions with this), i think in a matter of a few hours we can solve the Blender problem of collada import support. However as I said in previous mails, I really lack the time to get familiar with Blender internals and do this myself. Cheers Juan Linietsky On Tue, Jan 10, 2012 at 11:30 AM, Erwin Coumans erwin.coum...@gmail.com wrote: Until Blender has good fbx import or an alternative collada import (python?) it would be good to postpone dropping OpenCollada. From the feedback, some people are using the import feature, and there is no replacement. Let's hope someone stands up and fixes the issues in trunk, rather then branch. On Jan 10, 2012 2:15 AM, Ton Roosendaalt...@blender.org wrote: Hi, The Collada conformance suite is not working, and working on it won't help anything. I wrote about this here; http://code.blender.org/index.php/2011/10/collada-momentum/ Collada just has no reference stakeholder(s) (like how fbx was native for motionbuilder). Blender would be the worst stakeholder for it even, since we have the awesome .blend :) Much better stakeholders would be Linden Labs (2nd life), or CryTek... or Daz? Three names of companies who make plenty of dollars with software licensing. Why don't they put an employee as developer in our team, to ensure Collada exports smoothly for their products? I even wouldn't mind a (python) addon Export to DazCollada, CryCollada, 2ndLifeCollada, etc. It's how collada has been designed to work anyway... -Ton-
Re: [Bf-committers] Patches Submitted
I've needed to try and figure this one out too so here's my two cents and some random matrices. Since Blender uses column major order matrices these printouts are actually visually transposed to normal math, actual matrix columns are shown horizontally in the inner brackets and rows are vertical. So the 2.5 in a*b ((a*b)[2][0] - column 2, row 0) is a result of dot produt (a row 0, b column 2) as it should be - dot( (1.0, 0.0, 1.0, 0.0), (0.5, 1.0, 2.0, 0.0) ). a Matrix((1.0, 0.0, 0.0, 0.0), (0.0, 1.0, 0.0, 0.0), (1.0, 0.0, -1.0, 0.0), (0.0, 0.0, 0.0, 1.0)) b Matrix((1.0, 0.0, 0.0, 0.0), (0.0, 1.0, 0.0, 0.0), (0.5, 1.0, 2.0, 0.0), (0.0, 0.0, 0.0, 1.0)) a*b Matrix((1.0, 0.0, 0.0, 0.0), (0.0, 1.0, 0.0, 0.0), (2.5, 1.0, -2.0, 0.0), (0.0, 0.0, 0.0, 1.0)) b*a Matrix((1.0, 0.0, 0.0, 0.0), (0.0, 1.0, 0.0, 0.0), (0.5, -1.0, -2.0, 0.0), (0.0, 0.0, 0.0, 1.0)) One nice thing about this is that the columns are the axises (0,1,2) and translation (3) of a matrix, so a camera direction for example would be -a[2][0:3]. 2011/7/20 Campbell Barton ideasma...@gmail.com On Wed, Jul 20, 2011 at 3:37 PM, Scott Giese scott.gi...@comcast.net wrote: Hi Gang, FYI. I submitted 3 patches for your review. I'm new to the list and I wanted to give back to the Blender community. 28030 SCONS Build: Build Date reflects http://projects.blender.org/tracker/index.php?func=detailaid=28030group_i d=9atid=127 1 instead of actual date of build 28031 Minor typo in Blenlib http://projects.blender.org/tracker/index.php?func=detailaid=28031group_i d=9atid=127 28032 Python Mathutils: Matrix Multiplication Error http://projects.blender.org/tracker/index.php?func=detailaid=28032group_i d=9atid=127 Great work guys! Appreciate the great product. Scott Thanks for the fixes, committed all patches however you're changes to mathutils effectively only change the order of multiplication, http://projects.blender.org/tracker/index.php?func=detailaid=28032group_id=9atid=127 In you're example print (m1 * m2) Change to... print (m2 * m1) This is a bit confusing because in C we have mul_m4_m4m4(m1, m2); which is the equivalent to m2 * m1 in python. A while back Benoit Bolsee was concerned our matrix multiplication order was wrong so we switched it (between 2.4x and 2.5x) What makes you think the order in blender is wrong? what's you're reference? Just checked and we're currently doing matrix multiplication differently to numpy which doesn't bode well :S - test: # --- snip m1 = ((0.0, 0.0, 1.0, 0.0), (-1.0, 0.0, 0.0, 0.0), (0.0, -1.0, 0.0, 0.0), (0.6, 0.0, -0.05, 1.0)) m2 = ((1.0, 0.0, 0.0, 0.0), (0.0, 1.0, 0.0, 0.0), (0.0, 0.0, 1.0, 0.0), (0.0, -0.02, -0.1, 1.0)) from numpy import matrix n_m1 = matrix(m1) n_m2 = matrix(m2) print(\nnumpy\n%r % (n_m1 * n_m2)) from mathutils import Matrix b_m1 = Matrix(m1) b_m2 = Matrix(m2) print(\nmathutils\n%r % (b_m1 * b_m2)) # --- output numpy matrix([[ 0. , 0. , 1. , 0. ], [-1. , 0. , 0. , 0. ], [ 0. , -1. , 0. , 0. ], [ 0.6 , -0.02, -0.15, 1. ]]) mathutils Matrix((0.0, 0.0, 1.0, 0.0), (-1.0, 0.0, 0.0, 0.0), (0.0, -1.0, 0.0, 0.0), (0.62, 0.1, -0.05, 1.0)) # --- switch m1/m2 order for both mathutils and numpy. re-run numpy matrix([[ 0. , 0. , 1. , 0. ], [-1. , 0. , 0. , 0. ], [ 0. , -1. , 0. , 0. ], [ 0.62, 0.1 , -0.05, 1. ]]) mathutils Matrix((0.0, 0.0, 1.0, 0.0), (-1.0, 0.0, 0.0, 0.0), (0.0, -1.0, 0.0, 0.0), (0.6, -0.0, -0.15, 1.0)) ___ 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
Re: [Bf-committers] GE still slow in rev 36978
I attached a patch there which moves the letterbox drawing to happen only once per BGE render. Atm. with Use Frame Rate the BGE is drawn occasionally while the letterbox gets redrawn on each while(!exit_requested) iteration as fast as it can go. 2011/5/29 Sanne sa...@lavabit.com Hello Mitchell, Please add a new bug report. Done: http://projects.blender.org/tracker/index.php?func=detailaid=27517group_id=9atid=498 Thank you, Sanne ___ 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
Re: [Bf-committers] Bullet physics update
I am sorry, I wasn't being clear; my intention was that there'd be a bpy-side python function that would start gameengine with the only intent of exporting a bullet-file (similarly to what I do with 2.49b). Would not require much coding since this would would effectively use the same c++-code as the bge-side function. I don't know if there are some hidden problems to this and I think both bge- and bpy-export functions are required since they serve different purposes. Bpy-version would just provide clean access for exporting the data. Newbie, be patient please :) 2011/3/3 Mitchell Stokes moguri...@gmail.com Joshua Leung's (Aligorith's) GSoC project last year involved Bullet simulations in Blender (without using the BGE). I think he updated Bullet in his branch. You might want to have a chat with him. Cheers, Mitchell Stokes On Wed, Mar 2, 2011 at 2:23 PM, Erwin Coumans erwin.coum...@gmail.com wrote: The BGE already has a perfect location for such 'exportBulletFile' method in KX_PyConstraintBinding.cpp This would only be around 10 lines of code, and I will add this debugging/export option soon. Doing it outside of this KX_PyConstraintBinding.cpp might require much more work.It requires an up and running Bullet physics world btDiscreteDynamicsWorld. Is someone volunteering to do this work? Thanks, Erwin On 2 March 2011 14:11, Juha Mäki-Kanto kiskos...@gmail.com wrote: Hi, As Dalai Felinto said, I use the 2.49b export patch atm. to get the physics data out of blender. I do this from makefiles so I've added a GE commandline param (-g) export_physics = filename; with it the gameengine initializes, does export and sets exitrequested to true before the main-loop. All in all it's not neat so a bpy-function with similar results would be nice from a model-exporters perspective, possibly with an init_bge_pyscript-parameter which would allow advanced users to create things only available from within the GE. I'm pretty new to bullet and blender development so I'm not sure what problems this would cause compared to just having a purely bge based solution. Thanks, Juha 2011/3/2 Mitchell Stokes moguri...@gmail.com Nice to see you around again Erwin! bpy is available in the BGE if you're running from inside Blender. However, not from the Blenderplayer. Since this is more of a debug thing, I think this would be acceptable. Cheers, Mitchell Stokes On Tue, Mar 1, 2011 at 11:38 AM, Erwin Coumans erwin.coum...@gmail.com wrote: Hi, That is a good idea but I don't think it is a full replacement unless BPY is available within the BGE. Having the option to export within the BGE allows you to 'debug' and export a full running simulation. Some constraints/joints are only added at run-time (vehicles for example). Is BPY that can access a running Bullet simulation, available inside BGE? Thanks, Erwin On 1 March 2011 11:23, Dalai Felinto dfeli...@gmail.com wrote: Hi Erwin, I plan to add a single BGE physics API to export to a .bulle file, for example exportBullet(char* fileName); What if instead of a BGE API you do it as a bpy API? That way one can write an addon to export the .bulle files. It should already be possible now, but having an API for that can be easier I guess. (as a matter of fact Juha Mäki-Kanto, who submitted the RigidBodyJoint patch, uses Blender exactly for this, to export the .bulle for his engine) -- Dalai ___ 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 ___ 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
