| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
| |
- Added optional line stippling based on texCoords to the rotate1 line ring shader.
- Redesigned the CameraController and added the ability to zoom, dolly, dolly-zoom, and pan using the mouse.
BUG=none
TEST=none
Review URL: http://codereview.chromium.org/486003
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@34235 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
| |
Review URL: http://codereview.chromium.org/460097
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@34095 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
| |
render surface.
Review URL: http://codereview.chromium.org/469011
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@34033 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
manipulators.
I only did it on the rotate1 manipulators
because it was easy. On the translate ones
you either need to put each shape on it's own
transform so you can set the parameters different
or you need the materials to use different named
parameters.
Review URL: http://codereview.chromium.org/463025
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@33900 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
functions.
The issue is that JavaScript has no concept of
overloaded functions. Nixysa was merging them
for compilation by the JSCompiler but it needs
to keep them separate for docs.
To fix the issue an option was added to nixysa
to rename overloaded functions with the suffix
xxxOVERLOAD<num>xxx. The docs generators
then remove the suffix where appropriate.
Review URL: http://codereview.chromium.org/462039
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@33859 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
| |
Review URL: http://codereview.chromium.org/460065
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@33790 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The issue was that lineprimitves.js creates
an object that inherits from something in
primitives.js but because it appeared first
in the compiled version the inherit command
failed since the object it inherited from
was not yet defined.
It might be possible to make build_docs.py
move all the inherit commands to the end
of the compiled o3djs libs. I'll have to
look into it.
In the meantime here is a manual fix.
Review URL: http://codereview.chromium.org/464030
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@33773 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
geometry.
- Creates a basic CameraController class. It allows the user to rotate the camera around a center position using the mouse, and outputs a view matrix.
- Changes the Rotate1 manipulator to display as line geometry. Adds a line ring primitive and a special shader.
- Merges changes to Rotate1 sample into Translate1+2 samples as well. We probably should refactor the samples so we don't have duplicate code.
R=gman,kbr
BUG=none
TEST=none
Review URL: http://codereview.chromium.org/465023
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@33747 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
| |
I missed one of your comments in the last CL
Review URL: http://codereview.chromium.org/464009
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@33636 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
support both not picking invisible objects and
the option to pick even if invisible.
The idea is you can do something like this
// Make a picking manager
var pm = o3djs.picking.createPickManager(rootTransform);
... // add a bunch of transforms.
// generate picking objects.
pm.update();
// Get the picking object that was created for some specific transform
var info = pm.getTransformInfo(someTransform);
// Set properties on that object related to picking
info.pickEvenIfInvisible = true;
I think this is just a first step. How an object should
be defined as pickable is up for debate. As it is,
you can basically override info.isPickable.
as in
info.isPickable = function() {
// do something custom.
}
You can also start adding things easier like
info.onPick = function() {
// do something.
}
and then write code like
info = pm.pick(worldRay);
if (info) {
info.onPick();
}
While you could have done that before there was no
easy way to find a the TransformInfo for a
specific Transform. Now you can use
PickManager.getTransformInfo
Review URL: http://codereview.chromium.org/452027
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@33632 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
| |
those. Remove libo3dautoplugin.so properly.
Review URL: http://codereview.chromium.org/431010
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@33586 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
| |
Fix for last CL
I was testing in the wrong client :-(
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@33388 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
| |
the implemtation of createShape
Review URL: http://codereview.chromium.org/453010
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@33367 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
| |
1) Object type specifications "Object<index, type>" were broken
2) The js compiler would create a partial base.js even on failure
which means the next build would skip building the docs.
Review URL: http://codereview.chromium.org/457011
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@33366 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
| |
Chrome tree at src/gpu.
Review URL: http://codereview.chromium.org/442013
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@33115 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
| |
and into lineprimitives.js.
I refactored to code to share a lot of stuff
with primitive.js.
Review URL: http://codereview.chromium.org/435039
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@33041 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
a separate transform graph and render graph from
the main scene's.
two more things
1) added a scale to one transform in the scene
to show an issue with manipulators that might
need to be fixed
2) changed the material used by the manipulators
to be constant. This is on the path to making
the manipulators be line primitives instead
of geometry.
Review URL: http://codereview.chromium.org/434060
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@33040 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
| |
space).
BUG=none
TEST=none
Review URL: http://codereview.chromium.org/413007
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@32958 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
FencedAllocator to manage the transfer buffer
with less waiting.
Also updates glBufferData to use glBufferSubData
to send data as well as glTexImage2D to use
glTexSubImage2D. These make it possible to
pass any size image or buffer data.
Review URL: http://codereview.chromium.org/436020
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@32949 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
| |
This excersized more code and found several
bugs.
Review URL: http://codereview.chromium.org/437020
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@32891 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
| |
Review URL: http://codereview.chromium.org/434012
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@32864 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
| |
BUG=none
TEST=none
Review URL: http://codereview.chromium.org/395012
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@32596 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
| |
Review URL: http://codereview.chromium.org/415004
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@32576 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
| |
BUG=25245
TEST=Install O3D plugin for 32-bit Chrome, visit about:plugins, shutdown Chrome. This should not result in a crash.
Review URL: http://codereview.chromium.org/402092
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@32554 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I'm not sure if I should check the demo in or not.
I expect it will be moved or deleted but I'd like
to get it in.
This demo currently only runs on Windows because
of a few setup issues. All it does is clear the screen
purple then yellow.
It shows a tiny C segment including only gl2.h and
calling a GL function. Also a tiny C++ segment
including only gl2.h and calling a GL function.
The setup code is currently in the gles2_demo.cc.
I'd like to move to gles2_lib.cc but it needs
to be NaCl specific for that since that's the use
case for generic setup.
WebGL and unit tests will have to do custom setup I
think.
Also, I found out glGetAttribLocation and
glGetUniformLocation were not implemented. For now
I mostly subbed them out. The quickest solution
was to add class GetGLcharHandler to the
code generator but my next step will be to delete
class GetGLcharHandler and GLcharHandler given
that they only represent 3 functions total that
code should be written manually.
Review URL: http://codereview.chromium.org/399108
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@32546 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
| |
users system. If we detect libGLEW is not present on the system, prompt user to install using their package manager and abort o3d instal.
Review URL: http://codereview.chromium.org/391058
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@32519 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
| |
Review URL: http://codereview.chromium.org/404035
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@32433 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
| |
and fix includes so service side and compile
with system GL and client side can compile
with Command Buffer GL.
Review URL: http://codereview.chromium.org/407006
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@32429 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
with Chrome base.
(Sorry for the trouble. I didn't realize that O3D had a separate DEPS entry for chromium, so none of this was actually necessary ... sigh).
Note: when you do roll forward chromium past 32206, you'll have to roll skia to 428 at the same time.
BUG=none
TEST=please be green
TBR=gspencer
Review URL: http://codereview.chromium.org/404018
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@32273 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
| |
BUG=none
TEST=does it build?
Review URL: http://codereview.chromium.org/397033
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@32266 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Mac. Due to unfortunate limitations in gcc and gyp, this required creating a new static library target, skia_sse2 (see skia.gyp for the gory details). I did a search-and-replace in all .gyp files in the tree, but if there are other projects outside this tree which refer to skia.gyp, they will have to be modified as well.
This also required rolling DEPS for O3D Skia 376:428, since O3D uses chrome's skia.gyp file. Since this update brings ~25M of HTML docs, I pared the DEPS file down to just src/ and include/ (as we do in Chrome). I built O3D on 32bit Linux to test; hopefully other platforms will be ok.
BUG=none
TEST=green bots
Review URL: http://codereview.chromium.org/402016
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@32206 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
interface.
Moved np_utils classes into new np_utils namespace.
Removed some of the command_buffer dependencies on NPAPI.
CommandBuffer(Server) is no longer an NPObject.
Review URL: http://codereview.chromium.org/387063
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@32119 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There's a HUGE amount of TODO here that I will do in
following CLs but I wanted to get this in so people
can comment and see progress. Assuming there are no
bugs (cough) it should be possible to get a GLES2.0
program up with this assuming setup is implemented.
A few things:
*) Many files are auto geneated. They are generally
made as _autogen.h files and inlcuded into .cc files.
That way, as .h files they can be added to gyp but
not get compiled and it leaves the parts that
are better hand edtied outside of the auto generated
files.
*) there is a special switch to generate the
id tests. That's because the IDs MUST NOT CHANGE
and so therefore should not be auto generated.
*) I'm deliberately choosing to checkin the auto
generated files. I think it's important that changes
be explicitly reviewed instead of just reviewing
the generator. So, the generator is run manaually
for now.
*) I will end up most likely copying and pasting
the relavent lines from GLES2/gl2.h direclty
into the builder. The problem with reading it
directly is that changing the gl2.h file changes
the commands but commands are NOT ALLOWED TO CHANGE
once we ship and putting the lines directly in
the builder will make this more explicit.
TODOs:
*) Wrap glGetError with our own error bits so
some of our commands can set those bits.
*) Auto generate unit_tests. I'll work on this
once I get a demo working because I want to be
able to let others use this ASAP.
*) I want to change a few low level things
related to immediate commands. One of the problems
with this system is the commands are generated
from gl2.h instead of designed like they were
with O3D. In O3D, each command that passes
data has an explicit size. In GL, some sizes
are implicit like glTexImage2D. For an
Immediate cmd, a command where the data
follows the cmd, the cmd needs to know the size
of the data.
This is a problem because that size needs to be
known in 3 places. (1) where space is allocated
in the command buffer to write the command (2)
when the header to the command is filled out and
(3) When the address of the next command is
computed when not using the GLES2CmdHelper.
Currently it is computed in all 3 places instead
of just once. I need to think about how to refactor
so that that info is only computed once.
It might mean one more level of indirection. So,
for example, you look at
BindAttribLocationImmediate you'll see it
takes a const char* and inserts the name into
the command buffer for you. It might need to be
that that structure expects you to put it in
yourself and some higher-level thing like the
GLES2CmdHelper deals with putting the data in?
I'm not sure. I like the idea that calling
Cmd::Init or Cmd::Set makes the command perfect,
no outside stuff needed.
Thoughts are welcome.
*) We need to change the CMD header to either
a 32bit command followed by a 32bit size OR
a 10-11bit command followed by a 21-22bit size.
That would allow for say 256 common commands and
768 specific commands. Enough? The
issue is that the Immediate commands are
FAR MORE EASY TO USE because no synchronization
is required. So for things like
BindAttribLocation it's much much easier to use
the Immediate version. The problem is, with an
8bit size, the largest amount of data you can
pass is 1024 bytes. That's not large enough
for a shader and certainly not enough for a
buffer or texture and it would be nice
to be able to to use those commands as often
as possible in NaCl apps.
*) I need to track glPixelStore
*) Need to fix several commands that need
a size.
*) Need a ton of work on validation. We
need to make sure no enums not specified
by GLES2.0 can make it through to the
underlying GL. Also many places need
to check that the size of data about to be
accessed is valid for the given shared
memory or immediate data.
*) I'm planning to implement a named bucket system.
The specific issue is that some commands take
an arbitarily large amount of data. glBufferData,
glTexImage2D, glShaderSource, glGetShaderSource,
etc.
Right now if your command buffer or shared memory
segment is too small to transfer the data you'd
have to allocate a bigger one. Rather than
force that solution on you I want to implement
versions of those commands that use named buckets.
The bucket commands would let you Set a bucket
or append to a bucket and then you could reference
those buckets with the commands above. Example
int bucket_id = 123
cmdSetBucket(bucket_id, "first part of shader text");
cmdAppendBucket(bucket_id, "next part of shader text");
cmdShaderSourceByBucket(shaderId, bucket_id);
These bucket management commands would be added to the
common command buffer stuff so they could be used with
any command buffer. This is mostly useful for GLES2
emuliation and exposing command buffers stuff to
JavaScript like WeBGL. If you are writing a NaCl app
and talking direclty to the command buffers then you
can allocate your own shader memory the size of the
largest piece you need, or use other methods but
for example in the case of WebGL or GLES2 emu there
are no limits.
buffers
*) Should we add some kind of error reporter to
the service that the client can get
a handle on so that you can easily check for
errors? I suppose calling glGetError once a
frame is good enough? The advantage of a
service side is that it could more easily
tell you about "mal-formed command" and other
parse / validation errors that don't fit
glGetError.
*) There are several unimplemented commands.
Questions:
*) Should I separate calling GL from decoding the
same way O3D decodes, then calls GAPI? At this
point and it would slow down the decoder so I
don't really see a point but I can put
it on a low-prioirty todo if we want it later.
*) Should we support client side indices with
glDrawElements. They would have to be copied
to the server and verified every single call to
glDrawElements so it wouldn't be useful except
for porting code. The argument against is that
glVertexAttribPointer can also take client side
data and yet I don't think that data is used
at the call and therefore can not be validated
so if we can't do one maybe there's no point in
doing the other.
Review URL: http://codereview.chromium.org/394013
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@32109 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
| |
Review URL: http://codereview.chromium.org/385125
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@32084 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
| |
issues.
Review URL: http://codereview.chromium.org/384104
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@32075 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
| |
Review URL: http://codereview.chromium.org/384102
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@31866 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
| |
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@31859 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
| |
to move to Chrome tree.
Review URL: http://codereview.chromium.org/392017
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@31854 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
| |
BUG=none
TEST=none
Review URL: http://codereview.chromium.org/382001
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@31841 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
| |
Use this command to set it:
svn propset svn:eol-style LF <path>
Review URL: http://codereview.chromium.org/384095
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@31824 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
| |
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@31813 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
files with these names / extensions.
c
cc
h
mm
txt
idl
py
js
html
css
gyp
gypi
xml
shader
json
htm
README
DEPS
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@31811 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
| |
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@31692 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
| |
BUG=None
TEST=None
Review URL: http://codereview.chromium.org/384035
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@31690 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
| |
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@31682 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
| |
gpu/gpu.gyp
gpu/command_buffer/...
gpu/gpu_plugin/...
gpu/np_utils/...
And fixed up paths and header sentry macros. Also merged command_buffer.gyp into gpu.gyp.
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@31676 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
| |
This CL enables a 64-bit of linux. Set target_arch='x64' in the gyp defines to enable.
- fixes a few 64-bit issues
- fixes some linux build issues on scons vs make
- add rules to build 64-bit version
Review URL: http://codereview.chromium.org/371078
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@31642 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
| |
convention.
Review URL: http://codereview.chromium.org/372077
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@31570 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
| |
preparation for moving from NPAPI to Chrome IPC for synchronous messages.
Started work on an O3D configuration that will use Pepper 3D to connect to a remote GPU plugin. This is not building yet.
Updated to latest NPAPI from nixysa.
Review URL: http://codereview.chromium.org/371074
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@31519 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
| |
stats and uploading with others which required a modification of the stats uploading code to actually save old stats--which it should do anyways.
Review URL: http://codereview.chromium.org/295043
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@31502 0039d316-1c4b-4281-b951-d872f2087c98
|