| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I thought it was best to give you what I have so far
for your input and code review instead of giving you
everything all at once.
This CL implements JSONObject which has a mechanism
for adding stuff to be serialized as JSON to the
serialization code. Since JSONObject is a serialization
only object it seemed okay to put Serialize code
inside.
I opted to pre-declare JSONFloat and JSONOptionalFloat
because I felt it made the code more error free.
I had made it were you could just have JSONFloat and
then with RegisterJSONValue you'd pass in optional
or not but this way, declaring the field in a class
makes it more explicit.
CameraInfo is the first class that uses it. I'm not
set on exactly how it is serialized. Whether it's
as "object: { ... }" inside the "properties" section
or whether it should have its own section. I think
I won't know what until I actually write the
deserialization code. That's not imporant for this CL
This code, even if checked it, is not used yet
as the import code, collada.cc, is not yet creating
any of these objects. That's in another CL if you want
to take a look
http://codereview.chromium.org/160007
That CL will have to have lots of o3djs changes,
corresponding sample changes and corresponding
selenium test changes.
Review URL: http://codereview.chromium.org/160008
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@21515 0039d316-1c4b-4281-b951-d872f2087c98
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
with typical collada files found on the net.
Often someone will export a collada file with absolute paths
like "z:\someplace\somewhere\texture.tga" and
"k:\shared\stuff\othertexture.tga"
The converter needed a way to handle these without requiring
an artist to manually edit XML files.
I also refactored the original_data_ stuff to make sure
we don't get 2 datas for the same path. I'm doing that
in prepartion for shortening the paths where possible
using base-path or some mechanism.
Review URL: http://codereview.chromium.org/159118
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@21352 0039d316-1c4b-4281-b951-d872f2087c98
|
| |
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The previous code only support names up to 99 chars.
This one supports up to 1024. The code actually
supports 32bit length but given that Linux, OSX and
other only support 255 I set it 1024. Why 1024?
Because Windows actually supports 255 wchar characters
which when converted to utf-8 could be up to 1024 bytes.
I'm not 100% sure the format is correct. I could not
find any docs on the format, Just reverse engineered it.
Looking at hex dumps by both 7zip and gnu tar it was
pretty clear what it does including zeroing many
of the standard fields.
Review URL: http://codereview.chromium.org/159129
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@21210 0039d316-1c4b-4281-b951-d872f2087c98
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Bitmaps and being able to flip them, scale them, etc...
Basically this just makes it possible to download a RawData
directly which you can then pass you'll be able to pass to
pack->CreateBitmapFromRawData.
Some design comments:
I used SetFromFile instead of making a different constructor
since it seemed wrong to do file IO in a constructor. Given
that SetFromFile is private I don't think this is a problem
since you can't call it directly.
Also, I thought about loading the file first and then calling
the original constructor but it seemed like a waste to load
the file into memory, then copy it to a new buffer when I could
just load it directly.
Finally I made it take a String instead of a FilePath because
it meant other places had to do less work.
Review URL: http://codereview.chromium.org/149784
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@21015 0039d316-1c4b-4281-b951-d872f2087c98
|
| |
|
|
|
|
|
|
|
|
| |
and one for building import lib), so that the chrome build can depend only
on the archive.gyp file to reduce its dependencies.
It also adds a missing gyp file for the tests.
Review URL: http://codereview.chromium.org/149623
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@20638 0039d316-1c4b-4281-b951-d872f2087c98
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
I'm a little concerned that it renames the shaders
which means the developer has no way to lookup
"phong.fx" etc but I didn't see an easy way
to get that info out of the collada file from
the FCollada API. But he can at least look up
the name of the Effect from Max.
Review URL: http://codereview.chromium.org/149498
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@20458 0039d316-1c4b-4281-b951-d872f2087c98
|
| |
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
because the collada exporters often set it to NONE or POINT.
Also make it change any collada standard Material
that is used by a Primitive with no normals to use
"constant" shading. This should make sketchup stuff
work.
Review URL: http://codereview.chromium.org/147192
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@19545 0039d316-1c4b-4281-b951-d872f2087c98
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
| |
build to succeed.
Review URL: http://codereview.chromium.org/118346
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@17865 0039d316-1c4b-4281-b951-d872f2087c98
|
| |
|
|
|
|
| |
Review URL: http://codereview.chromium.org/118052
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@17392 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
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
|
