|
So, I'm continuing on my search for a proper non-fixed-pipeline introduction to OpenGL 3.x, and so far I'm still inexplicably coming up short, with the exception of the OpenGL ES 2.0 programming guide. Is ES close enough to vanilla OpenGL that I can more or less s/E(GL\w+)/GL\1/ and swap a few header files in and out? Also, I'm wondering precisely why everyone is saying to stay away from the Nehe tutorials. I've been glancing at them this morning and they actually seem better than the OpenGL Superbible, which I took out of the library a few weeks ago (which in my opinion has downright terrible code)? edit: ah, okay, well, I've just hit a point where it would have been obvious to use glPushMatrix() and glPopMatrix() but blows everything away with the identity matrix and recomputes everything... Or, is this the Forces of Destiny trying to tell me that OpenGL is all but dead on non-embedded devices and I should boot into Windows and do DX10 stuff instead? Dijkstracula fucked around with this message at 23:47 on Jun 27, 2009 |
# ? Jun 26, 2009 14:42 |
|
|
# ? Apr 18, 2024 04:12 |
|
Hey so I was wondering OpenGL how do you go about making a quad with a texture change colour? I want to apply some graphical effects to some sprites by making them flash white and lose opacity but i'm not sure if it's just the texture settings but I can't get it to work. Any help would be fabbo. edit: Found it through the TexEnv stuff. brian fucked around with this message at 16:33 on Jun 30, 2009 |
# ? Jun 30, 2009 15:37 |
|
Dijkstracula posted:So, I'm continuing on my search for a proper non-fixed-pipeline introduction to OpenGL 3.x, and so far I'm still inexplicably coming up short, with the exception of the OpenGL ES 2.0 programming guide. Is ES close enough to vanilla OpenGL that I can more or less s/E(GL\w+)/GL\1/ and swap a few header files in and out? ES2 is nothing like vanilla OpenGL, but will be close to OpenGL 3.2. OpenGL 3.0 doesn't exist. IT DOES NOT EXIST I TELL YOU. ahem. In ES2 you have to do almost everything by hand, to the point where you have to pass your matrices to your shaders yourself. There is no fixed function at all. This is a pain when you are starting out, since you have to write a ton of code just to get a quad on screen, but it is waaaay better in the long run since it removes stuff that really shouldn't still be in the API. Everyone says to stay away from Nehe because they are out of date and naive about how they do things. For example, in a real application you should never, ever, ever use Display Lists or call glBegin. All geometry should be put into a VBO and you should draw with that. It's ok for a very simple tutorial, but it really encourages bad habits, I feel. As for my previous comment on Geometry shaders, I mean that every implementation that's currently available sucks - especially under OpenGL. They're a great idea that has been very underwhelming to me thus far.
|
# ? Jul 2, 2009 01:19 |
|
Spite posted:ES2 is nothing like vanilla OpenGL, but will be close to OpenGL 3.2.
|
# ? Jul 2, 2009 06:47 |
|
Dijkstracula posted:Great, this is exactly what I wanted to know. It sounds like until the Red Book is updated for 3.2, ES is the way to go. I wish everybody else would follow that example. I fear NeHe won't be going away any time soon. It would be pretty cool if somebody did a GLES on top of the Windows OpenGL libs.
|
# ? Jul 3, 2009 03:32 |
How is the OpenGL experience in Java? Is it fairly similar to C++, or does the extra layer of indirection with memory management gently caress everything over?
|
|
# ? Jul 5, 2009 21:15 |
|
Jo posted:How is the OpenGL experience in Java? Is it fairly similar to C++, or does the extra layer of indirection with memory management gently caress everything over? I think it's absolutely horrible, even if you find a binding that doesn't create some over-engineered OO paradigm.
|
# ? Jul 7, 2009 21:32 |
|
Spite posted:I think it's absolutely horrible, even if you find a binding that doesn't create some over-engineered OO paradigm. Well, at least it's consistent with the rest of the language.
|
# ? Jul 7, 2009 21:33 |
|
Just as a sidenote - wow, there is really no resources out there for doing 2D scrolling games with OpenGL, for beginners like me - especially with ES. Yes I know it's mainly for 3D but for devices with Android or the iPhone it provides more power to do nicer looking games. If anyone can prove me wrong, please do! I've been looking for days and finding nada, zip, nothing!
|
# ? Jul 7, 2009 22:52 |
|
There is a separate iPhone dev thread that covers that a lot and seems to be a fan of cocoas2d.
|
# ? Jul 7, 2009 22:56 |
|
sex offendin Link posted:There is a separate iPhone dev thread that covers that a lot and seems to be a fan of cocoas2d. Well I must admit I don't have an iPhone - I'm mainly looking for Android-based development. There is an upcoming site, but they have nothing up yet and I was hoping to get something in for the Android Development Challenge But I suppose I could look at the source and see if it gives me some ideas
|
# ? Jul 7, 2009 22:58 |
|
Spite posted:I think it's absolutely horrible, even if you find a binding that doesn't create some over-engineered OO paradigm. You are wrong. LWJGL is a great binding. Uses native buffers to imitate float pointers and the like and the API is for the most part a direct binding. There is some Display classes and stuff to get it started that are not GL specific but all the openGL code will be. http://lwjgl.org/
|
# ? Jul 9, 2009 07:47 |
|
Strumpy posted:You are wrong. LWJGL is a great binding. Uses native buffers to imitate float pointers and the like and the API is for the most part a direct binding. There is some Display classes and stuff to get it started that are not GL specific but all the openGL code will be. I also had fun time using JOGL - https://jogl.dev.java.net/. It is relatively easy to translate C++ OpenGL program to this, you just have to use GL object, but it doesn't appear to be over-engineered or too heavy into OO, as it is still a state machine, you just do all your gl calls as function calls on an object.
|
# ? Jul 9, 2009 07:55 |
|
RussianManiac posted:I also had fun time using JOGL - https://jogl.dev.java.net/. From what I remember JOGL does a bit more then be a straight up GL wrapper. LWJGL (the gl portion at least) is a straight up wrapper. Functions have the same names and take the same arguments. It just pipes the commands down into native via JNI. I think JOGL tries to do more but it has been a few years (I jumped on the C++ bus). e: I was wrong about JOGL it is aparently 'just a binding'. quote:JOGL differs from some other Java OpenGL wrapper libraries in that it merely exposes the procedural OpenGL API via methods on a few classes, rather than attempting to map OpenGL functionality onto the object-oriented programming paradigm. Indeed, the majority of the JOGL code is autogenerated from the OpenGL C header files via a conversion tool named Gluegen, which was programmed specifically to facilitate the creation of JOGL. stramit fucked around with this message at 08:51 on Jul 9, 2009 |
# ? Jul 9, 2009 08:48 |
|
Strumpy posted:You are wrong. LWJGL is a great binding. Uses native buffers to imitate float pointers and the like and the API is for the most part a direct binding. There is some Display classes and stuff to get it started that are not GL specific but all the openGL code will be. Yes, but you are still using Java, which means you are adding a crapload of overhead to a type of programming that should be as efficient as possible. Crossing the boundary from the JVM into the GL library is a pretty expensive thing to do for every GL call.
|
# ? Jul 9, 2009 20:06 |
|
RussianManiac posted:I also had fun time using JOGL - https://jogl.dev.java.net/. I used JOGL on a simple university project a couple of years back. It was straightforward to use and got the job done. Don't recall any performance issues either.
|
# ? Jul 9, 2009 21:58 |
|
Digital Spaghetti posted:Just as a sidenote - wow, there is really no resources out there for doing 2D scrolling games with OpenGL, for beginners like me - especially with ES.
|
# ? Jul 9, 2009 22:19 |
|
Spite posted:Yes, but you are still using Java, which means you are adding a crapload of overhead to a type of programming that should be as efficient as possible. Crossing the boundary from the JVM into the GL library is a pretty expensive thing to do for every GL call. Not really. I did some benchmarks measuring FPS on programs i ported from C++/GLUT into JOGL and they were about the same. The only thing was slightly longer start up time and slightly more RAM used. Also its not expensive to cross from JVM to GL library because it uses JNI which is pretty efficient/fast. You can also use Java NIO native buffers which means that you shared native library for JOGL can directly use them. You can also minimize most of the GL calls you make same way its done in C++ programs. So if you do display lists, vertex arrays/buffers and other tricks you wont be calling that many GL calls anyway. JNI is a good way in general to speed up Java programs by first developing everything in Java and then identifying time critical parts and implementing those in C/C++ and using them from the rest of your Java App. RussianManiac fucked around with this message at 02:33 on Jul 10, 2009 |
# ? Jul 10, 2009 02:30 |
|
I'm using opengl es for the iphone. I have a very simple model that exists in 3d space, the problem is that the visible parts depend on the order they are drawn rather than their position in 3d space. So say the person has a shield in their left hand, then from the left view, you see the shield and can't see the body since it's being blocked. Now from the right side, the body should still be seen, but it's not. I figured out that this is since the shield is being added to the array last, if I make it first I get the opposite problem. How do I make it act like it should? Edit: Found a tutorial on Depth Testing. Works to some degree. I just need to to work with alpha properly. The texture is a square, and most of that square is see through, but when this square goes over another part it sometimes makes things see through as well.. Looks like order things are drawn is still important... It looks like if something is behind something it completely ignores it, even though part is visible, since the closer object is mostly transparent. Order is important since, if front object is drawn last, every thing looks great, but if front object is drawn first, things get wonky. Edit 2: http://books.google.co.uk/books?id=...result&resnum=4 that link seems to explain things well. Looks like I'm going to have to do some work. Edit: My solution. Drawing from back to front wasn't a real option. So I separated all the transparent parts and drew them separately at the end with glDepthMask(GL_FALSE); FSMC fucked around with this message at 13:27 on Jul 20, 2009 |
# ? Jul 20, 2009 11:28 |
|
Unparagoned posted:I'm using opengl es for the iphone. I have a very simple model that exists in 3d space, the problem is that the visible parts depend on the order they are drawn rather than their position in 3d space. So say the person has a shield in their left hand, then from the left view, you see the shield and can't see the body since it's being blocked. Now from the right side, the body should still be seen, but it's not. You really need to sort your transparent objects from back to front. Even if you draw them last, you need to draw them in order otherwise they won't actually be drawn correctly since the blending depends on what is already in the source buffer. Check out the OpenGL Red and Blue books for details. Also keep in mind that blending is slow, especially on the iphone.
|
# ? Jul 21, 2009 22:27 |
|
Spite posted:You really need to sort your transparent objects from back to front. Even if you draw them last, you need to draw them in order otherwise they won't actually be drawn correctly since the blending depends on what is already in the source buffer. Check out the OpenGL Red and Blue books for details. They blend fine, the order just says what transparent object is draw over the other. Since the transparent objects don't meet that often, I can live with it. It's pretty hard to notice anyway. Trying to sort them from back to front gives me a headache even thinking about it. These objects are the weapons of people, they parts move and the camera can move. I'd have to use ray tracing & allot of code to find out what the order should be. I think the performance hit doing this every frame would be too high.
|
# ? Jul 22, 2009 01:35 |
|
Unparagoned posted:I'd have to use ray tracing & allot of code to find out what the order should be. I think the performance hit doing this every frame would be too high. I'm not sure what you're trying to do here but lots of games depth-sort their sprites in real time so we must both be missing something.
|
# ? Jul 22, 2009 01:38 |
|
sex offendin Link posted:I'm not sure what you're trying to do here but lots of games depth-sort their sprites in real time so we must both be missing something. But how many iphone games depth-sort in real time? I may be completely wrong, it's just every time I think about how I would sort them, it seems very long, complicated and cpu intensive.
|
# ? Jul 22, 2009 02:01 |
|
Unparagoned posted:But how many iphone games depth-sort in real time? I may be completely wrong, it's just every time I think about how I would sort them, it seems very long, complicated and cpu intensive. If you have solid-ish particles, like rocks, metal flakes, foliage, etc; then you might want to consider the trick where you do one pass of the particles with the alpha ref set to reject all semi-transparent texels with z write and testing enabled, then a second pass with z testing still enabled, z writes disabled, and the alpha ref set back to allow semi-transparent texels. The edges won't sort properly, but it's often hard to notice since the solid part of the particle looks correct. Some more useful stuff here: http://realtimecollisiondetection.net/blog/?p=91 krysmopompas fucked around with this message at 04:02 on Jul 22, 2009 |
# ? Jul 22, 2009 03:51 |
|
krysmopompas posted:2 pass method That's a good technique, but you may not have the fill rate to burn on the phone. You can do a very crude sort and get a decent image (especially if you have lots of inter-frame coherency, as was mentioned), and it doesn't sound like you have too many objects in the scene - so that should be cheap.
|
# ? Jul 23, 2009 04:33 |
|
krysmopompas posted:
Thanks. I wasn't too sure what everything you said meant but starting playing with the idea of rendering twice. I ended up just drawing everything as usual(testing disabled). And then redrawing again with testing enabled. It's looks great and the performance hit isn't too bad.
|
# ? Jul 24, 2009 16:06 |
|
I'm trying to do displacement mapping after the projection matrix has been applied, but before perspective divide. Math gives me: (vertex + displacement) * Mproj = vertex * Mproj + displacement * Mproj However I'm getting artefacts: Without backface culling I have regions where backfaces get a higher z-value than faces that should be in front. In the attachement you can see the backside of the not displaced mesh overlaying the displaced mesh which should lie in front of it. code:
Somebody fucked around with this message at 01:55 on Aug 10, 2009 |
# ? Aug 10, 2009 00:02 |
|
code:
code:
Why would you want to do displacement mapping in projection space?
|
# ? Aug 10, 2009 12:13 |
|
shodanjr_gr posted:Why would you want to do displacement mapping in projection space? I'm doing adaptive subdivision surfaces, and I'm projecting the control mesh first and do the subdivision on the already projected points. This way I can calculate the error to the limit surface depending on perspective and I save a lot of matrix-vector nultiplications. I found my code works if I write matrix * vector instead of vector * matrix.
|
# ? Aug 10, 2009 18:46 |
|
heeen posted:I'm doing adaptive subdivision surfaces, and I'm projecting the control mesh first and do the subdivision on the already projected points. This way I can calculate the error to the limit surface depending on perspective and I save a lot of matrix-vector nultiplications. Interesting. So you only subdivide the points that actually matter to the viewer, that makes sense. Do you have any relevant papers that you can link to? I like learning new stuff .
|
# ? Aug 10, 2009 20:39 |
|
So, I feel pretty stupid at the moment trying to solve what I figure is a simple problem. I have two points, which can be used to make some vector leading from one point to the other. I simply want to place my camera such that it is positioned at one of the points (easy!) and looking along the vector path (I thought it was easy?!). What I need in terms of the rotation to look down the vector path is HPR (heading, pitch, roll). I am using OSG and Delta3D, but really I just want to know what I need to do in my math. I had thought I could simply create a look-at matrix and then retrieve the HPR from that. OSG has utilities to do both: osg::Matrix::lookAt(position1, position2, up) where conceptually position1 is the eye position, position2 is the center of the view desired, and the function returns a lookat matrix. From that, I thought I could retrieve my HPR values and set them to the camera - but this does not in anyway yield what I am looking for. The camera does move around, but only by coincidence does the lookat sometimes match what I want. I would also be greatly interested in good 3D math/linear algebra type books that are slanted toward programming for their examples.
|
# ? Aug 11, 2009 14:08 |
|
Luminous posted:I have two points, which can be used to make some vector leading from one point to the other. I simply want to place my camera such that it is positioned at one of the points (easy!) and looking along the vector path (I thought it was easy?!). heading and pitch are pretty simple to find with some trigonometry. code:
Not sure how you'd find roll. Surely you'd need a separate "up" vector, but I forget what you do with it. Sorry if this isn't what you're asking for. I don't know much about matrices, so that part of your question went over my head
|
# ? Aug 11, 2009 16:50 |
|
Luminous posted:Matrix stuff I'm not quite sure I understand what you are asking for, but if you can get a matrix you should be able to extract the values from it. The first column is the X axis, the second, the y, the third the z. The last is the position in that space. Is that what you are doing? Check out http://www.opengl.org/documentation/specs/man_pages/hardcopy/GL/html/glu/lookat.html
|
# ? Aug 12, 2009 00:16 |
|
I can get the values for HPR from a matrix fine. I am just not sure if I am actually making the matrix correctly (and given I am not visibly seeing the results I am looking for, I have to go with a "no, I am screwing it up in some way"). (or if I even need a matrix, in the case of magicalblender's math!) I am not sure how else to describe it. Let's say you are driving along and come to an intersection. You turn left. This is point 1. You drive to the next intersection on this road. This is point 2. At point 1 you can look toward point 2 by looking down the road. Pretend you are now a camera in the same space, and you see that in order to look down the road, you have to have some rotation such that you are looking along the vector defined by point 1 and point 2. I am trying to figure out that rotation. re: magicalblender - this seems to have better results than what I was doing, so I think it is on a usable path. The simplified case is to just make the heading of the camera follow the vector. IE, vector from point1 to point2 defines some heading where point1 is the origin, so in theory just applying that heading to the camera would see the camera looking along the same heading. And yet, my camera trips out like it's a groove machine!
|
# ? Aug 12, 2009 15:52 |
|
Did you look at any documentation for, say, gluLookAt()? The man page gives a description of the matrix that it constructs. (edit: durr, already posted! This is what I get for posting before coffee time.) But, re-reading your original post, if I'm reading it right, it looks like you're trying to use euler angles without first converting them into a product of rotation matrices (wherein you use your HPR angles to construct RzRxRy as your rotation matrix) Dijkstracula fucked around with this message at 16:09 on Aug 12, 2009 |
# ? Aug 12, 2009 16:03 |
|
http://kotaku.com/5335483/new-cryengine-3-demo Anyone got any info/links for the technique demonstrated by Cry-tek in the linked video? edit: http://www.crytek.com/fileadmin/user_upload/inside/presentations/2009/Light_Propagation_Volumes.pdf white paper here! shodanjr_gr fucked around with this message at 17:40 on Aug 12, 2009 |
# ? Aug 12, 2009 17:32 |
|
shodanjr_gr posted:http://kotaku.com/5335483/new-cryengine-3-demo At a guess from the "behind the scenes" section, it's a combination of the techniques for bloom and ambient occlusion. Each object must be producing a large color blob in an offscreen buffer somewhere which is then sampled by the surface shader for the environment. e: or read the whitepaper, yeah
|
# ? Aug 12, 2009 17:42 |
|
It's on Crytek's technology page. (edit: beaten by the OP!)
|
# ? Aug 12, 2009 17:50 |
|
shodanjr_gr posted:http://kotaku.com/5335483/new-cryengine-3-demo Oh come the f8ck on people! sure it looks great, sure its real time, sure its closer to photo realistic, but who cares?!!? Its not gonna make the game any better, some of the best games I've played looked like poo poo, and that is one of the most talked about issues of this gen, the fact that a LOT of man power goes to the graphics, rather than going on better AI/ideas/physics. I respect them for making such an advanced engine, but this simply shouldn't be of interest to the gaming industry, we're not watching a movie here, we're playing a game, and as seen in games such as Crysis , graphics dont make a game.
|
# ? Aug 12, 2009 18:05 |
|
|
# ? Apr 18, 2024 04:12 |
|
commenters posted:
|
# ? Aug 12, 2009 18:11 |