summaryrefslogtreecommitdiffstats
path: root/o3d/converter
Commit message (Collapse)AuthorAgeFilesLines
* Adding a no-binary path to the o3dConvertergman@google.com2009-09-041-1/+5
| | | | | | | | | | | | | | | | and deserializer. This CL still creates a o3dtgz file, it's just that buffers, skins and curves are stored in JSON instead of binary. I'm not sure how useful this is but it seemed like a possible short cut to testing out some stuff. Another CL will add some flag so there is no gzipped tar file, just the json. Review URL: http://codereview.chromium.org/189003 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@25523 0039d316-1c4b-4281-b951-d872f2087c98
* This adds in targets for selenium and updated several other problems,gspencer@google.com2009-09-041-7/+22
| | | | | | | | | | | including some problems with the samples and idl generation. Selenium targets launch selenium on all platforms, but the tests don't pass anywhere but Windows yet because the plugin isn't found. I'll work on that next. Review URL: http://codereview.chromium.org/197014 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@25467 0039d316-1c4b-4281-b951-d872f2087c98
* Update Texture::Lock to take an AccessMode.gman@google.com2009-09-011-11/+11
| | | | | | | | | | | | | | | | | | Also, split Lock/Unlock into common and platform specific parts. This is needed to work around an apparent bug in mac drivers where glGetTexImage apparently doesn't always work. This doesn't solve the issue unless we disallow READ completely. Not sure what to about that except make a small GL sample and report the bug to Apple. Review URL: http://codereview.chromium.org/173640 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@25012 0039d316-1c4b-4281-b951-d872f2087c98
* Prep for ascii only converter optiongman@google.com2009-08-313-5/+17
| | | | git-svn-id: svn://svn.chromium.org/chrome/trunk/src@24921 0039d316-1c4b-4281-b951-d872f2087c98
* Fixes toDataURL for GL by making it all work throughgman@google.com2009-08-282-28/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | O3D. What happens is client.toDataURL creates a RenderSurface and DepthSurface, sets those as the current Surface then renders. It then calls Surface::GetBitmap to get the pixels in the bitmap. The complications are 1) I needed to make Renderer::StartRendering / Renderer::FinishRendering be nestable because the Renderer::SetRenderSurface required StartRendering to already have been called. I didn't see a cleaner way to do this but I'm happy to change it if you have a better idea. 2) Since we can only create POT RenderSurfaces I added a clip_width / clip_height to render surfaces. Renderer::SetViewport uses these values so we end up rendering correctly to the top/left area of the POT render surface. 3) Doing it this way means that screenshots are NOT anti-aliased. I feel like that issue can be handled later. It's more important that toDataURL work now than it have the ultimate best results. (I hope). It probably means I'll need to create all new reference images. 4) I was wondering we we should expose SetClipWidth to JavaScript. Given that we require POT render surfaces they should always get the same results on all hardware. Or, rather, we could just allow the user to create NPOT RenderSurfaces. Under the hood they'd get a POT surface but the clip_width/clip_height would be set to the size the requested. There would have to be a note that texture wrapping only works if the size if POT. 5) I had to split FinishRendering into FinishRendering and Present since when taking a screenshot nothing will be drawn to the backbuffer and so I don't want a present to happen. Review URL: http://codereview.chromium.org/174594 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@24781 0039d316-1c4b-4281-b951-d872f2087c98
* Add license information to our shell scripts.agl@chromium.org2009-08-251-0/+3
| | | | | | | | | | Downstream packagers are (rightly) careful about the license of code that they distribute and so we want to dot our i's. http://codereview.chromium.org/174372 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@24311 0039d316-1c4b-4281-b951-d872f2087c98
* Cleanup Renderer.gman@google.com2009-08-253-34/+31
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | I believe there were some mis-understandings about the code. It's supposed to work StartRendering(); BeginDraw(); EndDraw(); BeginDraw(); EndDraw(); BeginDraw(); EndDraw(); FinishRendering(); To try to enforce correct usage I separated some platform dependant stuff from shared stuff and added a few flags. Also in this CL I made Texture::GetRenderSurface not require a pack. This is so I because it feels cleaner that way but also because I wanted to use surfaces without a pack to take a screenshot. Finally I put some screenshot code in for GL. Also fixed some bugs with locking textures. 1) I thought it was x, y, width, height but it's actually x1, y1, x2, y2 2) I was using width in places I should have been using mip_width Review URL: http://codereview.chromium.org/174199 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@24188 0039d316-1c4b-4281-b951-d872f2087c98
* Changes needed to make "all" build complete, including fixing the generated ↵maf@google.com2009-08-192-1/+20
| | | | | | | | converter tool. Review URL: http://codereview.chromium.org/173045 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@23721 0039d316-1c4b-4281-b951-d872f2087c98
* Change StreamBank to inherit from VertexSourcegman@google.com2009-08-171-8/+7
| | | | | | | | in preparation for Morph Targets Review URL: http://codereview.chromium.org/164483 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@23541 0039d316-1c4b-4281-b951-d872f2087c98
* Changes to Bitmap before exposing to JavaScriptgman@google.com2009-08-113-25/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This CL changes Bitmap to no longer be a cubemap. Instead there is a function, Pack::CreateBitmapsFromRawData that returns an array of bitmaps. For a 2D image 1 bitmap is returned For a cubemap 6 bitmaps are returned eventually for a volumemap N bitmaps will be returned. To distinguish between 6 bitmaps that are a cubemap and 6 bitmaps that are slices of a volumemap there is a Bitmap::semantic which tells what the bitmap is intended for. In a previous CL I had started to break Bitmap into classes like Bitmap8, BitmapFloat, BitmapDXT1. These were not intended to be exposed to JavaScript, only to make the internal code get rid of lots of if format == or case(format) stuff. But given that it's working as is and there are more pressing things I'm not planning to do that right now. I can delete the classes if you think I should. Note: This is still not 100% done. I still need to deal with the flipping issues or at least test. I probably need to add more tests as well. I also got rid of any mention of resize_to_pot in the command buffer version. Client side command buffer should not have to deal with POT/NPOT issues. I also moved the pot/npot stuff out of generic code and into the platform specific code. The generic code is not supposed to care. This is slower than the old way but it feels cleaner. A few issues I'm looking for input on. There's a function, Bitmap::GenerateMips(source_level, num_levels). It generates mips as long as they 8Bit textures. I can easily add half and float but not DXT. Right now if you call it on DXT in debug it prints a LOG message but otherwise it does nothing. Should I error for DXT? On the one hand it would be good to know that it failed so a user will not be wondering "I called it, why are there no mips?" On the otherhand, from JavaScript failing would mean you'd need to check the format before calling it which also seems less then ideal. The other is that currently it doesn't ADD mips, it just replaces the ones that are there. That means if you load a 2d image and want mips you have to allocate a new bitmap with the number of mips you want, copy level 0 from the old bitmap to the new bitmap and then generate mips Should I make generate mips effectively do that for you? Basically, if you call it to generate mips on levels that don't yet exist in the bitmap it would realloc itself and then generate them. Is that better? Also, I started down the path of taking out alpha_is_one. I'm trying to decide what to do with it. Part of me wants to take it out completely but since it's already there maybe I can't. If I leave it in I was thinking of making it check every time it's called. First I'd just make it slow. Then later if we want I could add a dirty flag and only recheck when it's dirty. That would be a lot of work though. It would mean wrapping Lock and SetRect and maybe a few other things so that we could catch any writes to the texture. It might also mean changing Lock to take read/write flags. I think those are good changes but again, it's not important right now. So, the question is what to do now. I can 1) Remove alpha_is_one. That might break something out there 2) Leave it in but just have it always false. 3) Make it check every time it's accessed. 4) Do the dirty flag thing. Preference? I'm for 2 or 3 I think. Review URL: http://codereview.chromium.org/164235 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@23051 0039d316-1c4b-4281-b951-d872f2087c98
* Moving the copy of d3dx_36.dll to a common location.bradnelson@google.com2009-08-111-16/+2
| | | | | | | | | | | | | Making it a copy by using a checked in copy if available or falling back on the system copy otherwise. BUG=None TEST=None TBR=gspencer Review URL: http://codereview.chromium.org/164297 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@22993 0039d316-1c4b-4281-b951-d872f2087c98
* Fixed some warnings in bitmap_png.ccbradnelson@google.com2009-08-101-0/+17
| | | | | | | | | | | | | | Switched to using the latest nacl and using their gyp files. Added a copy/rename step so that o3dConverter gets the dll it needs for other build steps. BUG=None TEST=None TBR=gspencer Review URL: http://codereview.chromium.org/164238 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@22891 0039d316-1c4b-4281-b951-d872f2087c98
* This CL adds client.toDataURL which gets the contentsgman@google.com2009-08-083-10/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | of the client area as a data url (which is a base64 encoded string of a png file) data urls are part of the HTML5 standard and supported by firefox, safari and chrome. http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#dom-canvas-todataurl That means you can now do this var dataURL = client.toDataURL(); // make an IMG tag display the screenshot someImgTag.src = dataURL; // use the IMG tag to draw into a canvas someCanvasContext.drawImage(someImageTag, ...); It also means there is no need for the test builds anymore "test-dbg-d3d", "test-opt-d3d" etc as toDataURL is part of the public API and can therefore always be used to take screenshots in any build. I updated the selenium code to use it. There are a few issues: 1) The GL version has the same limitations as taking a screenshot before. Namely that the client area must be on screen. We need to fix this. 2) We need to add support for origin-clean. See https://tracker.corp.google.com/story/show/180334 Review URL: http://codereview.chromium.org/164130 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@22869 0039d316-1c4b-4281-b951-d872f2087c98
* Add SetRect to Texture2d and TextureCUBEgman@google.com2009-08-031-14/+40
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Originally I was going to replace Lock/Unlock with only SetRect (and maybe GetRect) and I did that. But then as I was going through the code things started not being so cool. The JavaScript texture.SetRect where as before it allocated no memory, now it needed to allocate a temporary buffer just to be able to write the texture. DrawImage also would have have required copying the original texture out using GetRect, then modifying it, then copying it back even in D3D or it would have required a temporary buffer. That's what happens under the hood in the GL implementation of Texture2D but why should D3D suffer because of the of GL? Or maybe it's a reasonable compomise the D3D should go slower so that GL isn't twice as slow as it it could be? So, I left Lock/Unlock and added SetRect as well. This CL should help the video guys and we can decide if we want to get rid of Lock/Unlock later. SetRect is really only there because trying to make GL act like D3D makes GL slow since we had to get a copy of the texture from GL before Locking. SetRect, since it is not exposing the original data doesn't need to do that. So, now there are both. If need to read (and write) to the texture use Lock. If you only need to write use SetRect. I also fixed Lock/Unlock so they return a pitch which is required for D3D. While I did that I made Lock/Unlock private so you have to use the TextureXXXLockHelpers to access the data. I didn't do the command buffer versions. I also added stubs for texture tests. We need to add more tests. I feel like a lot of clean up needs to happen. It seesm like Bitmap should be split into Bitmap2D BitmapCUBE BitmapVolume Possibly. And maybe BitmapCube should effectively just be typedef Bitmap2D BitmapCUBE[6] and BitmapVolume would be std::vector<Bitmap2D> Then we wouldn't need face and volume versions of various functions. You'd just get the face or the slice Bitma2D and then use the 2D functions. We should decide if that's what we want before pushing a new release. Otherwise we should remove bitmap.idl from idl_scons.lst and the one sample And ship without exposing Bitmap until we are sure they API we are exposing is the one we want. Review URL: http://codereview.chromium.org/159725 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@22332 0039d316-1c4b-4281-b951-d872f2087c98
* Asynchronous tick now uses NPN_PluginAsyncCall.URL streaming callbacks are ↵apatrick@google.com2009-08-032-4/+14
| | | | | | | | now also asynchronous.Implemented NPN_PluginAsyncCall for IE.Allowed WM_PAINT handler to be reentered because it no longer calls into the browser (except to schedule an asynchronous tick if none is pending).Fixed a bug where the EventManager would crash if an event callback called cleanUp on the client.Cleanup destroys all the packs. Doing this in NPP_Destroy seems to make Chrome timeout and fail to load the next page.Tar and GZ decoding happens on a new thread. Review URL: http://codereview.chromium.org/155733 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@22305 0039d316-1c4b-4281-b951-d872f2087c98
* This adds the sample conversion to the GYP build, at least on Windows.gspencer@google.com2009-07-301-0/+1
| | | | | | | | | It also fixes some small problems with the build (naming of plugin DLL and activex host dll) Review URL: http://codereview.chromium.org/160428 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@22122 0039d316-1c4b-4281-b951-d872f2087c98
* Fix for linux againgman@google.com2009-07-241-1/+1
| | | | git-svn-id: svn://svn.chromium.org/chrome/trunk/src@21546 0039d316-1c4b-4281-b951-d872f2087c98
* Fixes for linuxgman@google.com2009-07-241-0/+1
| | | | git-svn-id: svn://svn.chromium.org/chrome/trunk/src@21523 0039d316-1c4b-4281-b951-d872f2087c98
* This updates the DEPS to bring them in line with the versionsgspencer@google.com2009-07-231-1/+1
| | | | | | | | | | | that Chrome is currently using, and it removes "files" from the NPAPI include paths and file location in third_party so that we can be consistent with other Chrome third party directories. TEST=build using gyp and scons and ran unit tests on each. Review URL: http://codereview.chromium.org/159277 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@21415 0039d316-1c4b-4281-b951-d872f2087c98
* Add --file_paths to converter to allow converter to rungman@google.com2009-07-233-3/+20
| | | | | | | | | | | | | | | | | | | | 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
* These are gyp file changes that start to make the Mac GYP build work.gspencer@google.com2009-07-221-0/+3
| | | | | | | | It still doesn't but I want to checkpoint these changes. Review URL: http://codereview.chromium.org/155890 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@21279 0039d316-1c4b-4281-b951-d872f2087c98
* This splits the import.gyp file into two parts (one for building archive lib,gspencer@google.com2009-07-141-1/+1
| | | | | | | | | | 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
* Add ClientInfogman@google.com2009-07-091-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This allows an app to ask a few things from the client. 1) How many objects the client is tracking. This is useful for a quick way to check that you're freeing resources. While the developer could use client.objects.length or client.packs[ii].objects.length that wouldend up creating hundreds of thousands of NPObjects. 2) Check if the software renderer is being used 3) Check the approximate amount of memory used by textures. Again, they could compute this with client.getObjectsByClassName('o3d.Texture') but it seemed like it might be useful. I say approximate because I would have to dig down into the indivdual renderers to get better info since a NPOT card will use more memory but it didn't seem worth it. 4) check the approximate amount of memory used by hardware buffers. Review URL: http://codereview.chromium.org/155276 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@20334 0039d316-1c4b-4281-b951-d872f2087c98
* Add o3djs.DestinationBuffer to converter.gman@google.com2009-07-071-1/+3
| | | | | | | | | 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
* Updates the o3dConverter to turn on filtering by defaultgman@google.com2009-06-293-4/+101
| | | | | | | | | | | | | | 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
* This adds in the GYP files needed for our GYP build,gspencer@google.com2009-06-241-0/+90
| | | | | | | 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
* This fixes a bunch of warnings that are in our code, in order for the GYP ↵gspencer@google.com2009-06-081-1/+1
| | | | | | | | 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
* This is the O3D source tree's initial commit to the Chromium tree. It gspencer@google.com2009-05-2721-0/+2143
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-01-22 16:57:35 +0000