awd-sdk's People
awd-sdk's Issues
C++ SDK Request
I have a small issue when textures are embedded into the AWD file.
The SDK doesn't write out the filename anymore. This causes a slight headache for importers that want to extract the texture data to file.
So, I would like to request that the local filename (w/extension) be exported for embedded textures too. It doesn't have to be set as the URL if that causes a problem. It could be added to the Properties section or perhaps the UserAttributes section at the end of the texture block. It doesn't have to be the full path either. Just the filename with extension is necessary.
Thanks
LZMA compression not working
The LZMA compressed files, that are produced by the AWD-Sdk, are not compatible with the as3 LZMA decompression.
See AwayBuilder Issue here:
Instantiate AWDGeomUtil crashes Maya 2014
I'm trying to put together a basic Maya AWD exporter, based on the available 3dMax exporter, but when I instantiate an AWDGeomUtil the software crashes immediately. To test the issue, I set a blank exporter (code attached), with a single instantiation on the writer function, and it still crashes.
#include <maya/MStatus.h>
#include <maya/MFnPlugin.h>
#include <maya/MString.h>
#include <maya/MStringArray.h>
#include <maya/MPxFileTranslator.h>
#include <maya/MGlobal.h>
#include <maya/MPlug.h>
#include <string.h>
#include <vector>
#include "awd.h"
#include "geomutil.h"
using namespace std;
class BlankPlugin : public MPxFileTranslator {
public:
BlankPlugin () {};
virtual ~BlankPlugin () {};
bool haveReadMethod() const { return false; }
bool haveWriteMethod() const { return true; }
bool haveReferenceMethod() const { return false; }
bool haveNamespaceSupport() const { return true; }
static void* creator();
MString defaultExtension () const;
bool canBeOpened() const { return false; }
MStatus writer ( const MFileObject& file,
const MString& optionsString,
MPxFileTranslator::FileAccessMode mode);
private:
};
void* BlankPlugin::creator()
{
return new BlankPlugin();
}
MStatus BlankPlugin::writer ( const MFileObject& file,
const MString& options,
MPxFileTranslator::FileAccessMode mode)
{
AWDGeomUtil util; // if this line gets removed it doesn't crash
return MS::kSuccess;
}
MString BlankPlugin::defaultExtension () const
{
return "awd";
}
MStatus initializePlugin( MObject obj )
{
MStatus status;
MFnPlugin plugin( obj, PLUGIN_COMPANY, "3.0", "Any");
status = plugin.registerFileTranslator( "Tester",
"",
BlankPlugin::creator,
"",
"",
true );
if (!status)
{
status.perror("registerFileTranslator");
return status;
}
return status;
}
MStatus uninitializePlugin( MObject obj )
{
MStatus status;
MFnPlugin plugin( obj );
status = plugin.deregisterFileTranslator( "Tester" );
if (!status)
{
status.perror("deregisterFileTranslator");
return status;
}
return status;
}
Using Maya 2014 on Mac OSX 10.7.5
C++ SDK issues
Hello,
I'm using the Away3D SDK C++, and I have encountered a couple of issues so far:
- The AWDMetaData class allocates its own memory for generator_name and generator_version,
but I don't see it de-allocating this memory anywhere.
The override_encoder_metadata() function doesn't attempt to delete any previous allocated memory. - The Importer side is completely missing. The SDK doesn't import AWD files.
Thanks
Refactoring cpp-libawd
Refactor cpp-libawd
The original cpp-libawd was created by other developers, that are no longer active on this project.
I have given my best to expand the cpp-libawd to include more awd features, but I never gotten comfortable with some of the coding-style used, so i am going to make a big refactor, to be able to comfortable be working on this.
Here is a overview over features and coding-style i like to introduce for next version cpp-libawd 3.0.
For the AwayExtensionsFlashPro, I already have a modified version of the cpp-libawd.
cpp-libawd in AwayExtensionsFlashPro
A big reason for the refactor of libawd is to get back to one version that can be used both for AwayExtensionsFlashPro3dsmax and AwayExtensionsFlashPro.
List of features that the new cpp-libawd should support:
- cross platform compatible
- support export and import all AWD3.0 features.
- support export and import of AWDProjects (AWD-files that share assets)
- helper functions:
- create texture-atlas
- convert color-materials to texture-materials (printing colors into texture-atlas)
- merge meshes (incl create texture-atlas and maintain animations)
- reduce joint-per-vert for skinning data
- remove unneeded bones from skeleton
- better helpers for file-handling and path-manipulation
- better geometry-utility, that allow to easily create AWDSubgeometries with custom streams
- well documented code (documentation created with doxygen).
Coding style / Design-Descisions:
- General: Keep in mind that the cpp-awdlib should be easily portable to python.
- Strings: At the moment the cpp-libawd handles all strings as char-pointers. I do not like char-pointers, when there is something available like std::string. Most occurrences of char-pointer will be replaced with std::string.
- Namespace: To provide name-clashes with other libraries, the complete code will be placed into the namespace โAWDโ. [edit:]Besides the AWD namespace, functions, types and classes will be grouped by "sub-namespaces" that are all inside the AWD-namespace.
- Lists: The cpp-libawd makes no use of std::vector. Instead c-style lists are used. Many c-style lists will be replaced with std::vector.
- GeometryUtil: in the new version, the user will no longer need to access the geometyUtil directly. We will now feed the AWDGeometry with the data, and than call AWDGeometry.process().
- Sources: Code will be distribute over more files, because this will make working on the cpp-awdlib easier.
- Type-casting: The cpp-libawd often needs to cast a AWDBlock into a class derived from AWDBlock. At the moment it uses c-style casting for this. This will be replaced with cpp-style casting (dynamic_cast<>)
Comments on this decisions are highly appreciated.
Unclear language in AWD PDF specification...
The section on Sub-geometry (page 21, last paragraph) in the AWD Specification seems unclear. The paragraph defines the term "sub-geometry" but goes on to use the term "sub-mesh" in its stead. It's unclear whether the two terms means the same thing or if they differ in some way.
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. ๐๐๐
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google โค๏ธ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.