|
kewlpc posted:Stay the hell away from NeHe's tutorials, they're terrible. Instead, start off with the ones by Nate Robbins, which are drat nice and even mentioned in the OpenGL Red Book. I disagree with this. There is some good stuff in NeHe's tutorials. I've got to admit that I don't read the text, but I still find myself dipping into the code sections occasionally to remind myself of how something works. Regarding Red and Orange books, just man-up and use the spec and extension definitions.  Seriously though, after a while, the spec is the only reference you really need. If you're doing any OpenGL programming you should have a copy of this handy. http://www.opengl.org/registry/doc/glspec21.20061201.pdf
|
#
¿
Dec 1, 2007 13:05
|
|
|
|
| # ¿ Apr 24, 2024 19:53 |
|
|
samiamwork posted:drat. I was afraid of that. I was really hoping to avoid using FBOs, but if that's what I have to use, that's what I'll use. Strange this should come up. I'm facing OpenGL fixed function blending woes right now myself. The imaging extensions add a few more blending modes (min, max, and so on) which might help. But the one that is really getting me, does anyone know of an efficient, NVidia compatible way, to perform a channel swizzle (copy A to R for example) that doesn't involve multiple buffer ping-ponging or using the color matrix extensions (which would be fine, but is a software only path even on Quadros)? What I really want is 1. Render Something with blending 2. Render the same thing in a different mode that will copy the result R from step one into A 3. Render something else blending using the new A value. Something like glCopyChannels(GL_RED,GL_GREEN, GL_BLUE, GL_RED) (which doesn't exists alas) For efficiencies sake I really need to do this using the fixed function blending (or other) pipeline.
|
|
#
¿
Dec 7, 2007 20:19
|
|
|
kewlpc posted:Again, use FBOs. Set up an FBO with two color attachments. Render Step 1 into color attachment 0. Switch to color attachment 1 and, using color attachment 0 as a texture, render a quad that covers the screen using a shader that just puts the red channel into the alpha channel. Cheers for your reply. As I mentioned in my post, for efficiencies sake I cannot afford to swap between two color attachments (ping pong) and keep them in sync. I am rendering tens of thousands of particles, the results of which need to be correctly composited with the results of all the previous particles. Your method would require swapping on each particle which would slow us to a crawl. The blending mode that we require cannot be directly implemented using the blending hardware (blending is still "fixed function" be it programable under the hood or not). We can however split the function into two parts if we could efficiently swizzle the RGBA channels (i.e. render and blend some initial parameters in R, then render again, swizziling R into A before the blend). The only way to do efficient Read-Modify-Write for large numbers of particles is using blending. We can swizzle channels using the color matrix functionality of the imaging subset (via an inplace copypixels and an appropriate matrix) but this drops to software on Quadro 4600 and 5600 cards.
|
|
#
¿
Dec 8, 2007 00:16
|
|
|
StickGuy posted:Have you considered presorting your particles? It is our last ditch approach. The particles are spawned based on user input (painting) and there can be a arbitary number of them created in a arbitrary order. Pre-sorting would mean re-rendering at least a subset under the new particle for each new particle added rather than a much more efficient in place rendering. If we can't find an elegant (read nasty hacky quick) solution we're gonna go this route. For efficiency we will probably use a combination of bucketing and viewport / scissor / stencil buffer to minimise particle redrawing. Roll on programmable blending.
|
|
#
¿
Dec 8, 2007 01:31
|
|
|
Mr_PK posted:I don't know if this is what you need or not, but in OpenGL you can use glColorMask(). This lets you limit what channels you want to render to. For example, you can only render to R and B, then do a second pass render to render to G and A. Cheers for the reply. We use color masking to control what gets written, but it is only half the solution. If only GL had a "render R as if it was blue" my life would be sooo much easier.
|
|
#
¿
Dec 8, 2007 01:34
|
|
|
kewlpc posted:But that's the complicated way of doing it. The simpler way would be to set up an FBO with only one color attachment, render Step 1 into it, then switch back to the default FBO, and render Step 3 using a shader that takes in your FBO's color attachment as a texture and uses its Red channel as alpha. Thank you!!!! I owe you an apology. We just got this method working a treat. Yay completely accurate floating point Photoshop-style brush painting fully accelerated in hardware. (Full speed with huge brushes that PS chokes on too) 
|
|
#
¿
Dec 8, 2007 02:50
|
|
|
kewlpc posted:Glad I could help. I would love to be able to say something, but for the moment I'm NDA'd upto the hilt and I work for an organisation that takes that sort of thing VERY seriously. I hope at some point in the near future to get permission to talk about it and even start giving it away. I'll make sure I post here first when I can.
|
|
#
¿
Dec 8, 2007 03:58
|
|
|
tyrelhill posted:The hardware usually pads NPOT textures to POT textures anyway, might as well remove that overhead and do it yourself. Do you have any literature backing this claim up? Specifically OpenGL 2.0 on Nvidia.
|
|
#
¿
Dec 19, 2007 22:47
|
|
|
Stanlo posted:Isn't that fairly well known? At least for older cards, which is what most people have. I've not seen any official documentation stating this and would be VERY interested in reading some. It's pretty important to me that I can keep an accurate handle on GPU memory usage. Yay for not having a glGetTextureMemoryUsage method.
|
|
#
¿
Dec 20, 2007 00:20
|
|
|
tyrelhill posted:Not exactly what I said, but this quote is from this book: Cool, Sounds like an interesting course. I'm not really bothered about pre-2.0 cards or low end cards either.
|
|
#
¿
Dec 21, 2007 00:49
|
|
|
TSDK posted:Looking good so far. Ooooh I invented something similar to this (but not as good) back in 2000ish. http://www.patentstorm.us/patents/6809729.html drat, "Don't publish but patent" companies.
|
|
#
¿
Apr 25, 2008 00:42
|
|
|
TSDK posted:What the hell? Issued 2004? Hell, I think I've almost got prior art on that sucker as well. This is the patent I wrote, I can't imagine why they wanted to patent it though. I since found out about 4 other people who "invented" the same method at about the same time as me. The main crux was the the ability to integrated pretty minimally into a fixed function GL pipeline. But it was first submitted in 2000 (in the UK at least) forelle fucked around with this message at 01:34 on Apr 26, 2008 |
|
#
¿
Apr 25, 2008 23:50
|
|
|
vanjalolz posted:I hear that NeHe is bad, but there is a LOT more stuff on there than Nate's website. I really really don't get the NeHe hate. Ok, it isn't professionally written, and they've stopped really updating it, so there are big gaps. But what there is is useful. It provides little test bed applications you can download and quickly play with which is sometimes all you really need. I've been coding professionally with OpenGL (both above and below the API) for 10 years now, and the NeHe stuff still comes in useful simply as repository of information in a compact form.
|
|
#
¿
Jun 10, 2008 23:33
|
|
|
|
| # ¿ Apr 24, 2024 19:53 |
|
|
MarsMattel posted:http://flipcode.com/iotd/2012-08-29 http://www.flipcode.com/archives/01-31-2002.shtml  My IOTD from 31st January 2002. 10 years ago. Talk about feeling old. I've learnt a bit about marketing and UI design since then.
|
|
#
¿
Aug 30, 2012 20:26
|
|
