Pages: 1 2 [3] 4 5 :: one page |
|
Author |
Thread Statistics | Show CCP posts - 45 post(s) |
Ferria
BetaMax. CRONOS.
12
|
Posted - 2013.07.25 14:15:00 -
[61] - Quote
So when can I get this kind of functionality for Dust514? why you gotta taunt us like this? |
Seismic Stan
410
|
Posted - 2013.07.25 14:20:00 -
[62] - Quote
CCP QC wrote:Hi all. Since this stuff is going rather well, me and CCP Veritas though it would be nice to push this to 11. So here we go: The vnd.ccp.eve.TournamentMatch-v1 resource now has two new optional fields: * firstReplayFrame * lastReplayFrame Both of these link to a TournamentRealtimeMatchFrame-v1 containing a pretty amazing amount of info =) Because it's easier to see for yourselves, just hit: http://public-crest-duality.testeveonline.com/tournaments/3/series/5/matches/2/realtime/0/A few notes on this: 1) Is this real life? yep 2) Will this persist post match/tournament/downtime? yes/yes/yes 3) Will this be updated in real-real time during the AT? These endpoints will update more or less in synch with the twitch stream, so in real-time, but delayed by 60 seconds to not leak too much information to participants 4) what happens during real time action if I GET a frame that doesn't exists yet?! I'll hold your request until it does. just make the GET and when it returns you should have your frame. Assuming all goes well. 4) Why?! OH GOD WHY?! I like a good challenge. o7 NINJA EDIT: these endpoints are under HEAVY dev right now, expect change on them.
This sounds like the beginning of something amazing. For a non-techie, could you explain what the applications of this are?
For instance:
Can it be used to build a battlerecorder which would play back the events in some kind of simulation?
Is CCP developing a graphical interface to provide post-match analysis during the tournament?
Can this be applied to data from engagements in EVE proper for the general use of PvPers?
Freebooted - Tech4 News - Incarna: The Text Adventure - Guild Launch EVE Correspondent |
|
CCP Veritas
C C P C C P Alliance
794
|
Posted - 2013.07.25 14:32:00 -
[63] - Quote
There are *significant* hurdles in the way of applying this technology to Eve in general. The tournament provides us a very bounded environment - 15 minutes max, 24 ships max, constrained location - which makes this sort of thing possible. CCP Veritas - Senior Programmer - EVE Software |
|
GizzyBoy
Aperture Harmonics K162
69
|
Posted - 2013.07.25 14:38:00 -
[64] - Quote
making me login to eve forums :P
no sleep for me to night,
Curses you devs you! ima try and bring so much extra alcomahole next fan fest, you can write off the the rest of MAY. |
GizzyBoy
Aperture Harmonics K162
69
|
Posted - 2013.07.25 14:48:00 -
[65] - Quote
CCP Veritas wrote:There are *significant* hurdles in the way of applying this technology to Eve in general. The tournament provides us a very bounded environment - 15 minutes max, 24 ships max, constrained location - which makes this sort of thing possible.
no the game data for your current pvp engagement couldnt be streamed in real time as the crest system has no way of knowing what pvp engagement your talking about.
What id like them to do however, is save the incoming stream of data pre tick that your client receives, and be able manipulate that data via one of the following.
You can save your engagements in a compressable small file size file. You can play the game in low quality settings, yet the stream will be able to be re rendered in any setting you wish. You can produce a video from the stream in highest video settings straight to file, You can direct the data stream to another rendering service in your local network to produce a completely rendered view, sans chat / possible system information, which can be passed directly to twitch / 3rd party streaming site.
|
Peter Powers
Terrorists of Dimensions Free 2 Play
141
|
Posted - 2013.07.25 14:52:00 -
[66] - Quote
nice demo :)
glad to see a bit more about CREST. i wish i would have had a bit more time at hand to toy around with it a bit before the AT :( 3rdPartyEve.net - your catalogue for 3rd party applications |
Peter Powers
Terrorists of Dimensions Free 2 Play
141
|
Posted - 2013.07.25 14:54:00 -
[67] - Quote
CCP Veritas wrote:There are *significant* hurdles in the way of applying this technology to Eve in general. The tournament provides us a very bounded environment - 15 minutes max, 24 ships max, constrained location - which makes this sort of thing possible.
well if you would provide an interface where i post a kill id, and it gives me the last 300 ticks of the grid where that kill occured, that would already allow for some amazing applications.
but for that you would need to record and store all ticks per grid, which probably is way too much data. 3rdPartyEve.net - your catalogue for 3rd party applications |
Makari Aeron
The Shadow's Of Eve TSOE Consortium
77
|
Posted - 2013.07.25 15:06:00 -
[68] - Quote
CCP FoxFour wrote:WEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE! Gonads and Strife?
Now if only CREST existed in tandem with SSO and allowed for all the current API endpoints ;) Keep up the good work! CCP RedDawn: Ugly people are just playing life on HARD mode. Personally, I'm playing on an INFERNO difficulty...
|
jonnykefka
Adhocracy Incorporated Adhocracy
220
|
Posted - 2013.07.25 16:04:00 -
[69] - Quote
CCP Veritas wrote:There are *significant* hurdles in the way of applying this technology to Eve in general. The tournament provides us a very bounded environment - 15 minutes max, 24 ships max, constrained location - which makes this sort of thing possible.
Understandable, but could we look mid-range future at a configurable on/off switch, the same way there's advanced camera tools for filmmakers? Playback is obviously it's own nasty beast but seriously the potential of this thing is tremendous. We have a couple of really great movie-makers in our corp, if we could record a fight (in w-space, so often following similar parameters to an AT match) and they had the tools to go back and re-shoot some of it with better camera angles and less UI?
Look, just from a marketing perspective this thing has amazing potential. What would you rather watch, a bunch of colored brackets at minimum visual settings or a ship blazing through combat with all of the art team's work on full display? You wouldn't even need to make trailers anymore! We would make them for you!
Obviously it's going to be a challenge to make it widely available, I fully expect that this is something that would take a year plus to make right, but consider this one more voice calling for you to put the work into it. |
|
CCP Veritas
C C P C C P Alliance
799
|
Posted - 2013.07.25 16:48:00 -
[70] - Quote
We put some more mildly ridiculous data at this endpoint: http://public-crest-duality.testeveonline.com/tournaments/3/series/6/matches/0/ CCP Veritas - Senior Programmer - EVE Software |
|
|
Zael Jun
Mohawk Battalion
0
|
Posted - 2013.07.25 17:50:00 -
[71] - Quote
CCP QC wrote:Luigi Thirty wrote:Why are you using your own MIME type instead of application/json? Why are you using nginx 1.2 which has more holes than a golf course? We use our own mime type to support being asked for different version of a resource by the clients. By sending in an accept header with the correct mimetype, say "application/vnd.eve.ccp.Tournament-v1" the server knows to return you that particular version. It allows us to release new versions of these resource and your client will keep working as long as we support the version you want. Asking the server with an accept header that doesn't match returns you the latest version of a particular resource.
This is not standard practice and I'll hope you reconsider. If you are returning json, your mime-type is application/json. If you need to version your API, as most APIs do, you should either change the resource identifier (/v1/endpoint to /v2/endpoint) or create your own header (e.g. API-Version: 0.00.1-build5290 if you must be so granular). I specifically say to use API-Header because, even though it is not a standard header, it is a header in common use for exactly this purpose. Further, RFC 6648 deprecates the use of X- headers in favor of all headers being treated like they could become acceptable standards in the future (as the API-Version header is very likely to do). |
Nicen Jehr
Brave Newbies Inc. Brave Collective
216
|
Posted - 2013.07.25 18:01:00 -
[72] - Quote
Zael Jun wrote:CCP QC wrote:We use our own mime type... say "application/vnd.eve.ccp.Tournament-v1" the server knows to return you that particular version. This is not standard practice and I'll hope you reconsider. If you are returning json, your mime-type is application/json... create your own header (e.g. API-Version: 0.00.1-build5290 if you must be so granular). I specifically say to use API-Header because, even though it is not a standard header, it is a header in common use for exactly this purpose. I am new to the dev/CREST party, if CCP put the versioning info in a header and set mime type to application/json - how would applications request a particular version?
Would my application send a GET request with a API-Version header? And the CREST response would contain its own API-Version header, hopefully the same as what I requested, and if not, the most recent version?
If that's an option it sounds like a better way to do it than repurposing MIME type. Little Things to improve GëíGïüGëí-á| My Little Things posts |
|
CCP QC
C C P C C P Alliance
30
|
Posted - 2013.07.25 18:12:00 -
[73] - Quote
I don't want to get into an argument over this, as the system will stay this way, but I disagree with the following:
Quote: If you are returning json, your mime-type is application/json
While I know that many use application/json as the "json" mimetype, I think this is wrong.
See, Json is not what I'm returning. Json is how I encode what I'm returning. The representation of the resource you are transferring is represented in a mimetype, say application/vnd.ccp.eve.TournamentTeam-v1, and the encoding of that representation is +json.
Should we decide to support xml in the future, you'd request application/vnd.ccp.eve.TournamentTeam-v1+xml
In any event, this is not going to change. If you don't like it, that's ok. But I think if you give it a try, you might fine that this way is quite nice to use.
TL;DR: no special header, no url /vX/ style. Give me an Accept header and if I can match it you get exactly that, if not, you get the latest available representation |
|
metiskafelez
Epidemic. Space Immigration
0
|
Posted - 2013.07.25 18:55:00 -
[74] - Quote
This is really cool! I can't wait to for this to go live on TQ, and see what streamers can do with it!
Also, to be a bit more on topic with where this thread is currently at. As a matter of preferred practice I like that the Mimetypes are open ended exactly for the above mentioned reason. The object that you are getting is JSON encoded, but not necessarily able to be consumed as a JSON object. |
Zael Jun
Mohawk Battalion
0
|
Posted - 2013.07.25 19:07:00 -
[75] - Quote
Nicen Jehr wrote:I am new to the dev/CREST party, if CCP put the versioning info in a header and set mime type to application/json - how would applications request a particular version?
Would my application send a GET request with a API-Version header? And the CREST response would contain its own API-Version header, hopefully the same as what I requested, and if not, the most recent version?
If that's an option it sounds like a better way to do it than repurposing MIME type.
Current best practice when using an API-Version header is to make it a request header. Some people say it should be required, but I think this limits the ability to RESTfully request without manually creating the request (e.g. if I access /endpoint and have authenticated in some fashion does version really matter? I think a default is okay and should be noted by the server in some fashion) and REST is supposed to be as simple, and logical, as possible.
Other options I've seen and like, but have little practice, is adjusting the Accept header, which supports arbitrary parameter. You could then send a request like this: Accept: application/json; version=2.0, application/json; q=0.1; version=1.0
That request would mean, "my application is compatible with 2 versions of the API, but I prefer the new one." the server would then respond with Content-Type: application/json; version: 1
This says, "yeah, you tried to access the resource using the new version, but this particular resource doesn't support the new version yet." (See RFC 2616 about the accept header and additional parameters)
All of these options have drawbacks, however. I don't know if the drawbacks are as bad as a non-semantic mimetype that changes with every version, especially when the mimetype is basically implementing the last example I gave in a very ugly manner. Here's the same example as above using CCP mimes:
Accept: application/vnd.eve.ccp.Tournament-v2+json, application/vnd.eve.ccp.Tournament-v1+json; q=0.1 Content-Type: application/json; version: 1
CCP QC wrote:I don't want to get into an argument over this I'm not arguing, I'm discussing the disadvantages of your implementation vs. the other options that are becoming widely accepted as best practices.
Quote:While I know that many use application/json as the "json" mimetype, I think this is wrong.
See, Json is not what I'm returning. Json is how I encode what I'm returning. The representation of the resource you are transferring is represented in a mimetype, say application/vnd.ccp.eve.TournamentTeam-v1, and the encoding of that representation is +json.
I'd have to disagree with your definition of a mimetype, but I can understand why you made your decision based on that definition. A mimetype identifies the encoding of a resource so that an application using the resource knows how to manage it (See original definitions and uses born out of STMP). By your definition, text/html is not a reasonable mimetype as, since it is my website, I should really be saying that the resource is of type text/vnd.zael-jun+html (after all, the HTML on my page is of a completely different format than any other page, even assuming i only use standard tags). This position is not reasonable. The resources is /zael-juns-site/endpoint, the encoding is text/html but, you know what, I also give my resources in application/json for the cool kids. The only thing that matters is that you know how to parse and use the resource, which you can do because I've used standard mimetypes.
Further, as I said above in response to Nicen Jehr, this implementation is really just smashing the Accept header parameters into one mimetype instead of using the ability to set parameters within the Accept header. I can see why you might be doing it for ease of use, and I'm sure you'll get along fine if you don't change it, I was merely pointing out more acceptable and standard ways of handling such problems. While this is your application, being such a big and powerful player out there I think it is a good thing to set good examples for those that will follow in your footsteps. |
Marcel Devereux
Aideron Robotics
263
|
Posted - 2013.07.25 19:19:00 -
[76] - Quote
CCP QC wrote:I don't want to get into an argument over this, as the system will stay this way, but I disagree with the following: Quote: If you are returning json, your mime-type is application/json While I know that many use application/json as the "json" mimetype, I think this is wrong. See, Json is not what I'm returning. Json is how I encode what I'm returning. The representation of the resource you are transferring is represented in a mimetype, say application/vnd.ccp.eve.TournamentTeam-v1, and the encoding of that representation is +json. Should we decide to support xml in the future, you'd request application/vnd.ccp.eve.TournamentTeam-v1 +xmlIn any event, this is not going to change. If you don't like it, that's ok. But I think if you give it a try, you might find that this way is quite nice to use. TL;DR: no special header, no url /vX/ style. Give me an Accept header and if I can match it you get exactly that, if not, you get the latest available representation
Why does the return type needs to be application/json?
|
l0rd carlos
Friends Of Harassment
546
|
Posted - 2013.07.25 19:19:00 -
[77] - Quote
CCP QC wrote:Hi all.
Since this stuff is going rather well, me and CCP Veritas though it would be nice to push this to 11.
Why don't you just make ten louder and make ten be the top number and make that a little louder? German blog about smallscale lowsec pvp: http://friendsofharassment.wordpress.com |
Marcel Devereux
Aideron Robotics
263
|
Posted - 2013.07.25 19:57:00 -
[78] - Quote
CCP Veritas wrote:There are *significant* hurdles in the way of applying this technology to Eve in general. The tournament provides us a very bounded environment - 15 minutes max, 24 ships max, constrained location - which makes this sort of thing possible.
So you mean those thousands of clients that currently connect to your system is using magic to get the physics data of objects into the client?
;-) |
Slvrsmth
Dreddit Test Alliance Please Ignore
1
|
Posted - 2013.07.25 20:12:00 -
[79] - Quote
Long ago, in a discussion far far away, there were magical words CREST and OAuth used in the same sentence. Any news on this, or have I been dreaming?
I'm asking because due to lack of information I've been starting to implement my own 'middleman' service (essentially, a OAuth-enabled API proxy, allowing small apps access to auth-protected data without having to manage API keys themselves) for EvE-related projects.
I started development due to lack of new CREST-related information, but if the project is still being worked on and will have such abilities (will it?) I'd be more than happy to stop and wait - a CCP-run service would be more 'legit'. And I wouldn't have to maintain it myself :)
So, is it feasible to expect such API functionality deployed against TQ data before, say, winter expansion?
PS Please use standard mime types - in my experience it's much easier for API consumers to work with additional header rather than merge that information into content-type. |
|
CCP QC
C C P C C P Alliance
31
|
Posted - 2013.07.25 20:14:00 -
[80] - Quote
Marcel Devereux wrote:CCP Veritas wrote:There are *significant* hurdles in the way of applying this technology to Eve in general. The tournament provides us a very bounded environment - 15 minutes max, 24 ships max, constrained location - which makes this sort of thing possible. So you mean those thousands of clients that currently connect to your system is using magic to get the physics data of objects into the client? ;-)
Well, that's partially the magic of Eve. The actual clients don't get x,y,z except when they or someone else joins a bubble. A part from that, they only get the "Dude X started orbiting Dude Y" or "Dude A started shooting dude B" events and the simulation is then synchronized. If no one clicks anything, even a 2000 man fleet fight produces just about no traffic.
The method we use here needs to store all x,y,z and send them down all the time, no local simulation. THAT doesn't scale well to 2000 ship fleet. |
|
|
|
CCP QC
C C P C C P Alliance
31
|
Posted - 2013.07.25 20:17:00 -
[81] - Quote
Slvrsmth wrote:Long ago, in a discussion far far away, there were magical words CREST and OAuth used in the same sentence. Any news on this, or have I been dreaming? ...
Yep, its been worked on. You'd need CCP Seagull to talk specific delivery dates. I'd say they are good chances of 3rd party apps being able to use our Single Sign On service for authentication before winter expansion, yes.
Doing that is the first step in then supporting registered 3rd party apps with write access to TQ.
|
|
Zael Jun
Mohawk Battalion
1
|
Posted - 2013.07.25 20:20:00 -
[82] - Quote
CCP QC wrote:Well, that's partially the magic of Eve. The actual clients don't get x,y,z except when they or someone else joins a bubble. A part from that, they only get the "Dude X started orbiting Dude Y" or "Dude A started shooting dude B" events and the simulation is then synchronized. If no one clicks anything, even a 2000 man fleet fight produces just about no traffic.
The method we use here needs to store all x,y,z and send them down all the time, no local simulation. THAT doesn't scale well to 2000 ship fleet.
Could you not provide that same level of expectation in this case? I mean, I don't really see a problem with people being expected to simulate some information. Is there a particular use case I'm missing? |
Nicen Jehr
Brave Newbies Inc. Brave Collective
216
|
Posted - 2013.07.25 20:20:00 -
[83] - Quote
A particular CREST endpoint might respond with one set of data for api-v1/json; and different sets of data for api-v2/json, api-v1/xml, and api-v2.xml. Since those cases contain different encoding and data the clients certainly must be able to differentiate between them.
I imagine that pretty much every REST client that is capable of reading MIME type and setting Accept headers should also be able to set API-Version headers in its requests, so my guess is that it would be too much work for devs to modify the CREST codebase to use headers instead of MIME type, and an executive decision has been made that this is adequate.
I don't see anything "wrong" about doing it with MIME types, I just think that it's a little smelly and CCP has the opportunity to set a nice precedent by using an API-version header (which would contain the same string as your current MIME type).
edit: also thanks for this, devs, i do appreciate it, just want to share my concerns before you open the entire CREST API for development Little Things to improve GëíGïüGëí-á| My Little Things posts |
|
CCP QC
C C P C C P Alliance
31
|
Posted - 2013.07.25 20:50:00 -
[84] - Quote
Zael Jun wrote:CCP QC wrote:Well, that's partially the magic of Eve. The actual clients don't get x,y,z except when they or someone else joins a bubble. A part from that, they only get the "Dude X started orbiting Dude Y" or "Dude A started shooting dude B" events and the simulation is then synchronized. If no one clicks anything, even a 2000 man fleet fight produces just about no traffic.
The method we use here needs to store all x,y,z and send them down all the time, no local simulation. THAT doesn't scale well to 2000 ship fleet. Could you not provide that same level of expectation in this case? I mean, I don't really see a problem with people being expected to simulate some information. Is there a particular use case I'm missing?
Let's not derail the thread too much, but in short: Distributed simulation needs to be 100% perfect. If your floating point library is off a tiny bit, the scene will desynch and you have no hope of recovery. Further, you need to know MUCH more than just "Dude A orbits dude B". How fast you orbit is influenced by a ton of stuff, collisions have to be computed in the exact same way. Of course, nothing is impossible, but for now we are experimenting with this positional data method.
Ultimately though, you are just talking to the wrong person =) Other devs are much better suited to talk about Destiny (that's the name of the simulation engine) then I am. |
|
Two step
Aperture Harmonics K162
4123
|
Posted - 2013.07.25 21:21:00 -
[85] - Quote
I am working on a viewer (get the URL from someone in the CSM Alumni channel), and I am running into a couple of problems:
1) I am trying to use your webGL library, but to do that I need to convert ship names/ids to resource paths (like res:/dx9/model/ship/amarr/at1/at1.red). It looks like the javascript file at http://web.ccpgamescdn.com/shipviewer/assets/shipresources.js has a partial list, but it doesn't have all ship types. Can you either include the resource path to the .red file, or poke someone to update that javascript with the full ship list?
2) My linear algebra is really rusty, and turning position + velocity vectors into a 4x4 matrix is hard. This isn't really your fault, but man, I thought I left linear algebra behind. :) CSM 7 Secretary CSM 6 Alternate Delegate @two_step_eve on Twitter My Blog
|
Marcel Devereux
Aideron Robotics
263
|
Posted - 2013.07.25 21:34:00 -
[86] - Quote
Two step wrote:I am working on a viewer (get the URL from someone in the CSM Alumni channel), and I am running into a couple of problems: 1) I am trying to use your webGL library, but to do that I need to convert ship names/ids to resource paths (like res:/dx9/model/ship/amarr/at1/at1.red). It looks like the javascript file at http://web.ccpgamescdn.com/shipviewer/assets/shipresources.js has a partial list, but it doesn't have all ship types. Can you either include the resource path to the .red file, or poke someone to update that javascript with the full ship list? 2) My linear algebra is really rusty, and turning position + velocity vectors into a 4x4 matrix is hard. This isn't really your fault, but man, I thought I left linear algebra behind. :)
I tried the argument that power is cheap and clean in Iceland and they should do the velocity calculation for us, but it didn't work ;-( Think of all the fossil fuel that will be burned by people writing inefficient algorithms to calculate velocity! Shame on you CCP for not being green! |
Rn Bonnet
Sniggerdly Pandemic Legion
11
|
Posted - 2013.07.25 21:37:00 -
[87] - Quote
Is there anyway I can talk you guys into setting the correct Content-Type type header on this stuff? JSON should have the following according to RFC 4627:
Content-Type: application/json; charset=utf-8
You are setting:
Content-Type: application/vnd.ccp.eve.TournamentRealtimeMatchFrame-v1+json; charset=utf-8
Which tricks out some libraries.
Edit: woops didn't see the rest of the discussion here feel safe to ignore. |
Two step
Aperture Harmonics K162
4123
|
Posted - 2013.07.25 22:09:00 -
[88] - Quote
Marcel Devereux wrote:
I tried the argument that power is cheap and clean in Iceland and they should do the velocity calculation for us, but it didn't work ;-( Think of all the fossil fuel that will be burned by people writing inefficient algorithms to calculate velocity! Shame on you CCP for not being green!
I don't want to calculate velocity, I need to turn velocity into a translation matrix for web gl. Any graphics/math guys want to step up and tell me what I need to do? CSM 7 Secretary CSM 6 Alternate Delegate @two_step_eve on Twitter My Blog
|
Rn Bonnet
Sniggerdly Pandemic Legion
13
|
Posted - 2013.07.25 23:17:00 -
[89] - Quote
CCP QC wrote:Zael Jun wrote:CCP QC wrote:Well, that's partially the magic of Eve. The actual clients don't get x,y,z except when they or someone else joins a bubble. A part from that, they only get the "Dude X started orbiting Dude Y" or "Dude A started shooting dude B" events and the simulation is then synchronized. If no one clicks anything, even a 2000 man fleet fight produces just about no traffic.
The method we use here needs to store all x,y,z and send them down all the time, no local simulation. THAT doesn't scale well to 2000 ship fleet. Could you not provide that same level of expectation in this case? I mean, I don't really see a problem with people being expected to simulate some information. Is there a particular use case I'm missing? Let's not derail the thread too much, but in short: Distributed simulation needs to be 100% perfect. If your floating point library is off a tiny bit, the scene will desynch and you have no hope of recovery. Further, you need to know MUCH more than just "Dude A orbits dude B". How fast you orbit is influenced by a ton of stuff, collisions have to be computed in the exact same way. Of course, nothing is impossible, but for now we are experimenting with this positional data method. Ultimately though, you are just talking to the wrong person =) Other devs are much better suited to talk about Destiny (that's the name of the simulation engine) then I am.
It actually scales fine, lets say you do a 32 bit floating point integer for the cords, of which you have 3. You can represent that in 10 bytes of ascii. So:
10bytes*3*2000=60KB (at max) assuming no compression (gzip can easily 1/4 that).
In terms of RPS if you just put a varnish in front of it you only get one to the back-end a second and you can scale horizontally all you want. Done and done.
|
Rn Bonnet
Sniggerdly Pandemic Legion
13
|
Posted - 2013.07.25 23:37:00 -
[90] - Quote
Two step wrote:Marcel Devereux wrote:
I tried the argument that power is cheap and clean in Iceland and they should do the velocity calculation for us, but it didn't work ;-( Think of all the fossil fuel that will be burned by people writing inefficient algorithms to calculate velocity! Shame on you CCP for not being green!
I don't want to calculate velocity, I need to turn velocity into a translation matrix for web gl. Any graphics/math guys want to step up and tell me what I need to do?
http://blogoben.wordpress.com/2011/06/05/webgl-basics-5-full-transformation-matrix/
Code examples at the bottom. |
|
|
|
|
Pages: 1 2 [3] 4 5 :: one page |
First page | Previous page | Next page | Last page |