summaryrefslogtreecommitdiffstats
path: root/o3d/serializer
Commit message (Collapse)AuthorAgeFilesLines
* This fixes a number of things that are warnings in the Mac compiler.gspencer@google.com2009-07-212-10/+12
| | | | | | | | | It fixes at least two real bugs, one in the tar generator, and one in stream_bank.h. Review URL: http://codereview.chromium.org/159168 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@21227 0039d316-1c4b-4281-b951-d872f2087c98
* Document the O3D binary formats.gman@google.com2009-07-111-0/+67
| | | | | | | | | | | | | | | | | | | | | | | | | | I just wrote up some small docs to kind of get this out of the way. If Josie wants to write a more formal doc to put on the website we can do that but at least with this it's documented. Going through it I have a minor concern. The Buffer format is fine because it spells out exactly how much data it expects. The Skin and Curve formats do not so if pass in a valid offset but an invalid length when you call Cuvre::Set(myRawData, validOffset, invalidLength) you get undefined results and possibly no errors depedning on what data it runs into. This may or may not matter as it's unlikely the user will get very far with an invalid length. The issue is just more that it's possible. Review URL: http://codereview.chromium.org/155246 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@20457 0039d316-1c4b-4281-b951-d872f2087c98
* Add o3djs.DestinationBuffer to converter.gman@google.com2009-07-072-1/+34
| | | | | | | | | I named it o3djs.DestinationBuffer because it has nothing to do with O3D. It's purely part of our sample serialization example. Review URL: http://codereview.chromium.org/149236 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@20013 0039d316-1c4b-4281-b951-d872f2087c98
* Adding in most of the unit tests. This adds 406 of our unit testsgspencer@google.com2009-07-011-3/+8
| | | | | | | | | into the gyp build. 21 of them fail, but that is only because they don't have test input yet -- I haven't added the build code that copies the test inputs into the build dir yet. Review URL: http://codereview.chromium.org/147129 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@19778 0039d316-1c4b-4281-b951-d872f2087c98
* This adds in the GYP files needed for our GYP build,gspencer@google.com2009-06-241-0/+39
| | | | | | | and modifies the DEPS file extensively to match. Review URL: http://codereview.chromium.org/131116 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@19091 0039d316-1c4b-4281-b951-d872f2087c98
* These are code changes required to make the GYP build work.gspencer@google.com2009-06-232-9/+9
| | | | | | | | | | | | | Mostly these are fixes to warnings (signed/unsigned mismatches were the most common), and some changes to include paths. I've updated the build.scons files and DEPS file to match these changes so that the scons build will still function with these changes. Review URL: http://codereview.chromium.org/146047 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@19062 0039d316-1c4b-4281-b951-d872f2087c98
* This CL makes the collada importer handle skinned datagman@google.com2009-06-091-4/+4
| | | | | | | | | | | | | | | | | | | | better. Specifically, it takes the original VertexBuffer and splits it. One VertexBuffer contains the parts fields that get skinned. (POSITION, NORMAL, etc...) The other VertexBuffer contains the fields that don't get Skinned. (COLOR, TEXCOORD, etc...) That way instancing you can share the non-skinned VertexBuffer. The next step is to not serialize the skinned VertexBuffer's contents. Review URL: http://codereview.chromium.org/118156 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@17942 0039d316-1c4b-4281-b951-d872f2087c98
* This is the O3D source tree's initial commit to the Chromium tree. It gspencer@google.com2009-05-277-0/+2486
is not built or referenced at all by the chrome build yet, and doesn't yet build in it's new home. We'll change that shortly. git-svn-id: svn://svn.chromium.org/chrome/trunk/src@17035 0039d316-1c4b-4281-b951-d872f2087c98
generated by cgit v1.1 at 2025-06-12 07:10:35 +0000