| Computers Forum Index » Computer - Graphics - API (Opengl) » Seperating vertex coordinates and texture coordinates... |
|
Page 1 of 1 |
|
| Author |
Message |
| Skybuck Flying... |
 Posted: Fri Oct 02, 2009 5:15 am |
|
|
|
Guest
|
Hello,
I am wondering if the following is possible:
One buffer object for vertex coordinates.
One buffer object for texture coordinates.
(Current examples only show one buffer object and vertex and texture
coordinates either interleaved or slapped on top of each other by an offset)
For the seperated buffer object idea the draw code could look something like
this, but I am not sure if it will work:
Bind texture coordinates buffer
Enable client state for texture coordinates
set texture coordinates pointer
Bind vertex coordinates buffer
Enable client state for vertex coordinates
set vertex coordinates pointer.
DrawElements, offset 0.
DisableClient state for texture coordinates
DisableClient state for vertex coordinates
Some questions:
1. Would this work ?
2. Would there be any adventages or disadventages performance wise ?
Bye,
Skybuck. |
|
|
| Back to top |
|
|
|
| Skybuck Flying... |
| Posted: Fri Oct 02, 2009 9:20 am |
|
|
|
Guest
|
Ok,
I just tested it,
This seems to work just nicely...
Don't know about the performance yet ;)
So far I will go with multiple buffer objects ;)
That way the indexes for positions and texture coordinates are the same:
Example:
mVertexPosition[0].etc
mVertexTextureCoordinate[0].etc ;)
^ Much text but ok :)
Bye,
Skybuck. |
|
|
| Back to top |
|
|
|
| Skybuck Flying... |
| Posted: Fri Oct 02, 2009 9:22 am |
|
|
|
Guest
|
Going to ban you know, you're useless
Bye,
Skybuck. |
|
|
| Back to top |
|
|
|
| Skybuck Flying... |
| Posted: Fri Oct 02, 2009 9:26 am |
|
|
|
Guest
|
Hmm not completely yet...
The dimension is 500x400.
The last 100 pixels/verteces on the right are not being drawn... hmmm...
They black.
Bye,
Skybuck. |
|
|
| Back to top |
|
|
|
| Skybuck Flying... |
| Posted: Fri Oct 02, 2009 9:35 am |
|
|
|
Guest
|
Ok problem solved, little calculation error:
Was:
vPositionY := vVertexIndex div 500;
vPositionX := vVertexIndex mod 400;
Had to be:
vPositionY := vVertexIndex div 500;
vPositionX := vVertexIndex mod 500;
However I discovered a new problem:
When this code
// gluOrtho2D(0.0, mRenderToTextureWidth, mRenderToTextureHeight, 0.0);
Is changed to this code:
gluOrtho2D(0.0, mRenderToTextureWidth, 0.0, mRenderToTextureHeight);
Then a black line appears on the top ?! <- Wacky ?!
(This also flips the Y... hmmm)
Bye,
Skybuck. |
|
|
| Back to top |
|
|
|
| Skybuck Flying... |
| Posted: Fri Oct 02, 2009 9:38 am |
|
|
|
Guest
|
Ah yes... GL_POINTS biting me in the ass again ! ;)
Must add +0.5 to each coordinate lol.
Problem solved ! ;)
Bye,
Skybuck. |
|
|
| Back to top |
|
|
|
| Skybuck Flying... |
| Posted: Fri Oct 02, 2009 9:48 am |
|
|
|
Guest
|
I did have to use glDrawArrays though... instead of glDrawElements like in
the example...
glDrawElements was causing an access violation... read of address 0000etc.
Probably because I did not define any indices...
Fortunately glDrawArrays does not need any indices...
For now the benefit of indices remains unclear to me...
I can imagine someone using indices to make construct object in a weird
way...
But I would use multiple vbo's... one vbo for each object...
Using multiple vbo's seems much easier to me...
Bye,
Skybuck. |
|
|
| Back to top |
|
|
|
| Charles E Hardwidge... |
| Posted: Fri Oct 02, 2009 1:50 pm |
|
|
|
Guest
|
It's worth a shot but I'll be surprised if you can penetrate the thick wall
around SF's brain and get him to change. I've seen people try it with Eep
in the games groups, and Scott Nestel in the 2000 Ad group and it got
nowhere. After 10 years the only thing that remains is frustrated people and
an empty newsgroup in both cases.
--
Charles E Hardwidge |
|
|
| Back to top |
|
|
|
| Skybuck Flying... |
| Posted: Sat Oct 03, 2009 1:18 pm |
|
|
|
Guest
|
I don't understand table 3.26 it's way too cryptic !
Simple statements like:
Component = OldComponent * alpha - NewComponent * alpha;
or
Component = NewComponent;
Would be clearer...
The table can be much larger in the horizontal direction...
Now it's just a small tiny little crappy cryptic table  <- sucks !
Bye,
Skybuck. |
|
|
| Back to top |
|
|
|
| Skybuck Flying... |
| Posted: Sat Oct 03, 2009 3:21 pm |
|
|
|
Guest
|
The algorithm for compressed textures is also unclear to me...
Pseudo code how to compress and decompress textures would be nice ;)
Bye,
Skybuck. |
|
|
| Back to top |
|
|
|
| Skybuck Flying... |
| Posted: Sat Oct 03, 2009 3:28 pm |
|
|
|
Guest
|
It does mention two compression formats at page: 425
S3TC and FXT1 ;)
Bye,
Skybuck  |
|
|
| Back to top |
|
|
|
| Wolfgang Draxinger... |
| Posted: Sat Oct 03, 2009 10:45 pm |
|
|
|
Guest
|
Skybuck Flying wrote:
Quote: The algorithm for compressed textures is also unclear to me...
It's exactly described in the specification. It is expected, that someone,
who want's to implement texture compression is familiar with algorithmics
and can implement an algorithms from a mathematical definition given in the
specs.
It is so, because you don't have to implement it, if you want to use
compessed textures. OpenGL can do all this for you. Maybe you already
realized, that in glTexImage<n>D you deliver two format parameters, which is
not redundancy:
- "internal format" which tells OpenGL which format to use internally
- "format" which tells OpenGL in which format the data is, you hand it over.
OpenGL will then apply the proper conversation. If you define a compressed
texture format as internal format, and a raw uncompressed format for data,
OpenGL will do the compression for you.
If you want to store your texture images in a compressed format, you can
read the compressed data from OpenGL using glGetTexImage, requesting a
compressed format via the "format" parameter.
Wolfgang |
|
|
| Back to top |
|
|
|
|
