Forum Replies Created
15 September 2016 at 10:06 in reply to: [SOLVED] Request to complete Documents>Using SOFA>Basic Components #7482
It sounds like it’s just Guillaume and Hugo doing everything which seems odd and unfair to you poor guys. Get some help. Students/interns are great to abuse. Apply for Google’s summer of code and others are great. Anyway you guys are doing a great job so keep it up.
“We decided to avoid having a 3 parts doc (website + wiki + doxygen) because it is harder to maintain and has duplicates risks (particularly between the website doc and the wiki).”
Yes and all software devs face this problem. But what you get is a static website and a doc that nobody knows how to read except for the original coders and even they are unsure because they forget. This why a living doc that all the developers, managers, users, etc use and rely on in step with the advancement of the codebase is more useful in the end. So it will not be just up to two guys to update documentation because all involved are looking to that doc and updating it. Getting the team on board to do it the trick of course but once done it goes smooth because that is what people want; most of the info they need in one place. Scripts can be used to pull info from dOxygen, Trello, etc that can really help to automate the process.
“It would be possible to have one page per component but wouldn’t it be better to have those tips & tricks in the Doxygen ?”
No. For a user hunting down this info in the dOxygen that is in a useful form never works out. It would be nice in theory though. Best to have it in the wiki made by the coder and also in the runSOFA gui component section. Every option needs a help flyout or link. Otherwise you get what it is now and you have options that are a number entry with no idea of what can be used.15 September 2016 at 09:22 in reply to: [SOLVED] Request for new Section under Components to explain how to make/edit/use #7481
No. You are clearly not understanding the topic unfortunately. Completing the “Components” documentation is one thing however how to proceed if this is not available is another thing entirely. Maybe read over “How does a developer look at the dOxygen doc and then from there create the xml and the GUI…”
Right now more than 150,000 users have downloaded and looked at the existing components and tried to figure them out without documentation. Most have given up. But if you could teach users how to figure any component out and write the xml, then you will have happy users. The “Programming with SOFA” section helps but more is needed thus this request.
Hi Eric I am pleased to hear that you have an interest in combining UE & SOFA. The usage scenario to start would be to crate a stand alone interface such as the runSOFA GUI combined with a PhysX editor to create the joints/constraints. Since UE uses Visual Studio continuing this would be best however that means building off the runSOFA is not possible as it is build in QT. But since a new GUI really is the way to go in the long run as to avoid any licensing issues and control over code that is ok. Unity3d and Blender can be looked at for inspiration on how to handle the physics constraints GUI and also there is a PhysX editor just released that is open source that will be a goldmine called PEEL which is a tool designed to evaluate, compare and benchmark physics engines and the good thing is that it abstracts the physics engine so adding in SOFA may be fairly easy and then we could have many physics engines to work with. I would also highly recommend studying the code and GUI of what the Digital Trainers (Clément Forest) did with SOFA Blender. It would be so nice to actually get the SOFA Front End tool they made to work and then it may be possible to get Unity3d and UE both to be working easily however their pricing model and closed source free release prohibits this. However the ultimate goal that may be out of reach but the best way to handle the joints/constraints is how the CAD programs do it such as SolidWorks and Fusion360. The CAD engines use a geometric constraints engine and are complex and I have not found a good open source one we could use. Plus they also are working with B-rep NURBS models however I think I may have found some ways it could be done. Anyway it would be cool if you could document your progress and have a GitHUb repository setup.
Can anyone describe the theoretical steps involved to combining SOFA and Unity3d? There is an established way to create a wrapper for C++ code and there is a Python interpreter.
This may seem a simplistic method that is based on ignorance but since Unity3d can use ‘Layers’ for visualization could it be possible to just run SOFA to that layer and then auto mesh the model in Unity3d. And since SOFA uses layers as well it could use the generated layer to be the bridge between the two engines so the SOFA model could interact with native Unity objects/environment. Andrey P24 August 2016 at 23:47 in reply to: [SOLVED] FEA Solver with SOFA to make Von Mises Stress color mapping #7399
My goal is to have a material type assigned to the mesh, then deformed from a collision from another model, and a visualization of the stress/strain. I’m sure this has been done many times and that there are packages out there that will not only do that but much more and easy to hook up rather than hand coding everything from pieces of a library. Dynamic real time solving is the goal.
I have been wanting SOFA and Unity3d together for years and asked around and even tried a little. Please look at the work done by digital-trainers.com that created a way to incorporate SOFA with other apps and they did as an example with Blender which is very cool but of course not fully realized for functionality and buggy (I really hope they continue to build it so let them know). They have a free version of the product but it’s not open source unfortunately and the source version is super expensive. But hey maybe you can get funding for it actually and it would get you a huge start on the project in a professional way and then you can work on really getting a good integration of all the SOFA features into Unity3d. Please let us know the GitHub or BitBucket etc info so we can help and try it out.
Blender SOFA is a version of the 3D modelling tool Blender that has been modified to propose SOFA as an alternative physical engine for the Game engine. That modification has been made using the Sofa Front-end library.
Blender SOFA is currently based on the version 2.74 of Blender and is currently only available for Linux and Windows (a Mac version is scheduled).
This first version of Blender SOFA is limited to only a small subset of all the SOFA models. We will complete it gradually according to the feedback we receive.
What can I do with it ?
You can use Blender SOFA for instance to ease the creation of your SOFA scenes, by taking advantage of all the functionalities provided by Blender.
The main functionalities of Blender SOFA are the following:
creation of the following deformable models:
regular and sparse grids,
collision models based on meshes,
fixed point constraints,
constant force fields,
constraints or penalty contact resolution,
iteration of the simulation in Blender,
export to .scn and .obj files, that can be read for instance by runSofa.
Request a way to PM someone. Can only do the public @name thing from the profile page. Will the @name message be sent to the users hidden email address or do they have to be on the RSS feed to get it? Anyway like other forums it should be easy to message someone and if they do not want to recieve messages they can just opt out.
The old site had lots of forum discussions with very valuable info especially from past developers responding to questions. Any chance of putting that up again so it can be searched?