I have been exploring Maya's blendshapes for the past weeks, and it has one very interesting feature called in-between targets. It basically allows one blendshape to include intermediate states between the two basic targets (modified and original objects). I created a couple and tried to export in FBX to use them in Blender, and I get an error message. This error does not occur when I import a FBX file without in-between targets in the blendshapes. Also, I wasn't able to find a pure Blender solution to create Shapekeys with in-between targets, which got me wondering if it is even possible.
Any help is appreciated.
Blender only provides support for one vector per vertex per shapekey so the in-between targets will not be able to be imported directly. I would suggest you report this as a bug, while I don't expect in-between shapekeys to be added any time soon, the fbx importer should be fixed to not break on these files.
One thing you could to try is to see if you can export the shapekeys to an mdd or pc2 file. Blender has a mesh cache modifier that can be used for these files. From 2.78 a new option to try is exporting to an alembic archive as outlined here
While blender doesn't support in-between shapekeys, you can create a comparable result using drivers. A single control can be made that can enable a series of shapekeys one after the other.
Related
I am using pandas to do some data analysis. Others in my company are wanting to process data in a similar fashion, but won't want to use a programming language to do it. After significant googling, I found Orange, which has the perfect interface for what I'm wanting people to do. However, the widgets don't do the types of tasks we're looking at. So, I decided to see if I could write my own widgets for Orange to do the tasks.
I'm trying to use Orange3; this seems like the best bet when I'm using WinPython. I must say that going through the documentation for widget creation (for Orange2) and the code for the Orange3 widgets is rather impressive - very nicely written and easy to use to implement what I'm wanting to do.
After writing a couple of widgets, how do I get them into Orange3? the widget creation tutorial is for Orange2 (in Python 2.7), and I haven't got it to work for Orange3.
My project is at the moment rather small:
dir/
orangepandas/
__init__.py
owPandasFile.py
pandasQtTable.py
setup.py
setup.py currently contains the following:
from setuptools import setup
setup(name='orangepandas',
version='0.1',
packages=['orangepandas'],
entry_points={'Orange.widgets': 'orangepandas = orangepandas'}
)
When I run python setup.py install on this and then try opening Orange3 canvas, I don't see my shiny new widget in its new group.
After tracing through how Orange3 imports external libraries, it seems that Orange relies on the actual widget file existing, rather than being inside a egg (zipped) file. Adding
zip_safe=False
to the setup options allowed Orange3 to import the widgets correctly. Orange3 uses os.path.exists in cache_can_ignore in canvas/registry/discovery.py to detect if the path exists at all, and if it doesn't, it doesn't try to import it. Using zip_safe=False makes sure that the addon stays uncompressed so that the individual files are accessible.
(For the next person who tries to do what I was doing.)
I am trying to use rotations and calibrations between different microscope coordinate systems (e.g. beam tilt, stage shift, CCD image/diffraction pattern) in DigitalMicrograph by using the calibrations present in the "Microscope Data.gtg" file. To do this I load the file and pull out the different calibrations. Is there an easier way to access individual calibrations?
To determine the orientation of the stage the script needs to know at what Magnification the Stage calibration was performed. In old versions of DigitalMicrograph there was a global tag called "Calibrations:Stage Calibration:Acquisition Magnification". However I could not find this tag in GMS2.1.
There have been changes in the code regarding calibrations between GMS 1 and GMS 2 which indeed are as you've described.
There is no easy access to the required information via the scripting language.
However, the solution you have described is indeed the best workaround.
I would like to use the halfedge data structure of CGAL in my project.
Since it is licenced by LGPL, I would prefer to distribute this small piece together with my software, instead of requiring the installation of this big library on the user's system.
So my question is, is there something like boost's bcp for Cgal? I started to manually copy the halfedge source files but it looks fairly compicated.
thank you in advance
There is currently no automated way to extract only a subset of CGAL headers or just a package including its dependencies. You can try to do this manually though by just following all include dependencies.
Even if you do this, the biggest problem is that CGAL assertions require linking to libCGAL. You can avoid this by disabling the assertions through the CGAL_NDEBUG macro. It's also not easy to see from a CGAL distribution if a package compiles code into libCGAL, but neither Polyhedron nor Halfedge_DS do that, so you should be fine.
We're planning to launch a serie of applications in AppStore. They will be for some kind of different journals, showing different contents downloaded from a server via XML. So these applications will be made from exactly the same code (It's an universal application, so It'll work both in iPhone/iPad).
My initial idea was, in order to upload the application, compile just changing the images, logos and configurations (plist) that makes the application react as a particular journal. The compressed file would be uploaded to the AppStore.
However, this has resulted a horrible method, which promotes failures and mistakes. If I forget to change some image, as you can't see them in the compiled file (as it is included) they will end up in the store (and I will need four or five days in order to get the application changed).
I'm trying to look up for a better approach, wich keep the projects as independent as possible. I would like to be able to share the entire codebase: views, classes and nibs and create different projects for every journal.
Which is the best method to achieve that?. What structure would let me group both logic (controllers, classes) and UI and use it in the different projects?.
I hope I've explained.
As always, thank you very much.
You should keep most of your common code as a library project. Each final project should link with this project and provide images/assets along with code to mention these assets to common code. In my day job, I write a common library too, which gets used by 2 products/apps at my employer.
An Xcode project can have multiple Targets, all the Targets sharing code, but each Target getting its own resources (icons, images, text, plists, etc.) from a different subdirectory/folder within the same project directory/folder. Then you can check the whole thing, or just the shared source, into your source control repository.
You should also be testing each of your apps, built exactly the same way as any submission except for the codesigning, on a device before uploading to the store.
You can have a single Xcode project that creates multiple applications. You'll need to create a separate Info.plist with a different bundle identifier for each app.
If you are using a git repository you can just branch for each different app you want and that would keep track of all the differences and if you need to switch which you are working on you just have to checkout that branch. This would allow for the exact same structure just minor differences between the actual code for each.
I have developed a large MSBuild project to build a portion of our solution. There's a lot of things going on-- XML parsing/replacing, Windows services, remote copy, etc. As a result, the file has grown really difficult to manage, despite my best efforts to add decorations in comments.
As a goof, I broke out the main chunks of functionality out into separate files, like "XML.targets", "Services.targets", etc and imported them into the main "Build.proj." The build still worked and I immediately found it to be much more manageable.
However, all the info I have read on the Import feature of MSBuild is that it should be used to import reusable targets, ie those than can be consumed by -any- MSBuild project without any modifications. The separate projects I'm creating here are the opposite-- specific to one project and will break by default if use with anything else unless modified.
So I guess what I'm asking is, even though I can... should I? Is there an inherent danger in using Import strictly for the purpose of organizing a large project? Is there a better way to do this?
Thanks
No, there is no inherent danger. I think it's a good decision to split large project into several .targets files specific to certain operation since it reduces overall complexity. The idea of creating reusable targets means that they should have as little dependencies on the other parts as possible. By analogy you can think of separate .targets files as classes. The less coupled they are - the better. Because modification in one targets file will less likely break the whole process. You can take a peace of paper, draw your targets files as points with your main project in the center and draw all the connections between them. Say if one targets file overrides target from another or expects some properties from it or somehow else depends on it then there is a connection. In the perfect scenario you'll get something like a star.
In short: you should if it reduces complexity.