• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
fir

OpenGL
question about sending ram->vram each frame

22 posts in this topic

I am only slightly experienced in opengl (i am mostly doing

2d on blitter stuff) and i would like to clear some things with it,

maybe some will help me to clarify..

 

As i understand you need to transfer (ram -> vram upload)

 two kinds of data :

- geometry data 

- texture data

 

as i understand texture data you only upload mostly once (at app startup) not each frame (except if you got not sufficient vram then you could destroy 

some upload some other, it is switch texture set for example between 

game chapters,.. but in general you do not do it on perframe basis) [is this correct?]

- also if you need tochange texture data you usually change it on vram side

by shaders.. [is this correct?]

 

more confused i am with dealing with geometry data :

 

here i am not sure but it seem to me that geometry data is in 

generall uploaded on perframe basis (it is you send heavy thousands of triangles each frame with cpu to gpu side - then after every frame 

the vram set of it is destroyed/cleared (which opengl call clears it?

i do not know the thing here..) for example even if you have vertex

array you need to send it (ram->vram) each frame

is this correct or not? are there some mechanism that prevents 

the uploaed geometry arrays on vram side and allow only for

manipulating them there? (for example heavy mesh is being uploaded to 

vram and it stays there for hundreds of frames you can only send some

parameters like modifile position matrixes for each mesh nodes not whole

mesh data? could someone clear the thing?

 

 

 

0

Share this post


Link to post
Share on other sites

No answers? this seem to be fundamental and important topics, important to get answer..

-4

Share this post


Link to post
Share on other sites

You already got the answer. You pass vertices once. As a general rule, they don't ever change.

 
 
If you moved your vertices, they'd accumulate FP math errors and your model would stop being the model you think it is.
 

You also got an example of how you avoid resending data using matrices in the answer. You were even told to look up more information by looking into skeletal keyframe animation. While 3TATUK2 obviously dumbed the animation explanation down, you should know enough from the explanation to effectively google about animation.

 

To help understand animation better, maybe you can think of a simpler animation where you pass 2 vertices into the vertex shader and a time variable. You use the time variable to do a linear interpolation on the two vertices to calculate the vertex you actually want to work on in the shader. Note that this is not matrices, but hopefully it gets you thinking about how you can deform a vertex in the shader to work on a calculated vertex instead of a directly specified one.

Edited by richardurich
1

Share this post


Link to post
Share on other sites

Technically, most of the answers to your question depend on what you are doing - but for efficiency, it's better to limit transfering from client to server (or vice versa) as much as possible.

 

Really, I suggest going through some tutorials, look up "modern OpenGL tutorials" or similar.  Make sure the tutorials are "modern" or at least version 3 or later.  For example, this one http://www.opengl-tutorial.org/ seems good, I believe it was one of the tutorials I skimmed through it when moving from XNA to OpenGL a year or two ago and found it helpful.

 

After you get the basics, going through the OpengGL wiki is helpful on the nuts & bolts aspects of OpenGL.

1

Share this post


Link to post
Share on other sites

Technically, most of the answers to your question depend on what you are doing - but for efficiency, it's better to limit transfering from client to server (or vice versa) as much as possible.

 

Really, I suggest going through some tutorials, look up "modern OpenGL tutorials" or similar.  Make sure the tutorials are "modern" or at least version 3 or later.  For example, this one http://www.opengl-tutorial.org/ seems good, I believe it was one of the tutorials I skimmed through it when moving from XNA to OpenGL a year or two ago and found it helpful.

 

After you get the basics, going through the OpengGL wiki is helpful on the nuts & bolts aspects of OpenGL.

maybe it may seem strange but i got not to much time for learning opengl - i just need some answers like here

(Im doing 2d blitter graphics for over a year not touching

ogl)

 

cannot them be just answered, they are quite simple?

-4

Share this post


Link to post
Share on other sites

Technically, most of the answers to your question depend on what you are doing - but for efficiency, it's better to limit transfering from client to server (or vice versa) as much as possible.

 

Really, I suggest going through some tutorials, look up "modern OpenGL tutorials" or similar.  Make sure the tutorials are "modern" or at least version 3 or later.  For example, this one http://www.opengl-tutorial.org/ seems good, I believe it was one of the tutorials I skimmed through it when moving from XNA to OpenGL a year or two ago and found it helpful.

 

After you get the basics, going through the OpengGL wiki is helpful on the nuts & bolts aspects of OpenGL.

 

I was only using some basic opengl, when i was drawing 

some basic opengl i sent a full vertex array each frame..

so what with that .. there is a way of sending all meshes 

at app startup and then sending only position matrices each frame?

 

as to this post of 3tatuk2 it was zero helpfull (belive me

i know what im saying ;\)

 

there is also subquestion of deleting the geometry data

- if i upload a large vertex geometry in the frame and it resides in vram then it seem that before sendoing it next frame some api call deletes the prevoius in the vram.. is this true? what api call this is?

 

as to moving the vertices i do not want to move the vertices by updating the vertex array but just use glRotate glTranslate but then it is again whole vertex array sending (uploading)... is this correct way of writing programs or this is bad way at all?

Edited by fir
-4

Share this post


Link to post
Share on other sites

as to this post of 3tatuk2 it was zero helpfull (belive me
i know what im saying ;\)


No, you don't. Creating a VBO and putting the vertex/index data in there (just like 3TATUK2 said) is the exact way you avoid uploading the identical data to the graphics card every frame.

The first Google result for 'VBO' is even this Wikipedia page which, while not perfect, gives a very decent introduction to the concept.
1

Share this post


Link to post
Share on other sites

If someone tells you how to do something (transfer data only once to GPU using OpenGL in this case), you can safely assume it is possible. You seem upset that nobody explicitly said it is possible, but I'm not sure what other conclusion could be reached. It is the reason I did not reply to the original post. I felt I could add nothing of value beyond what 3tatuk2 said.

 

You can load your textures and vertices (meshes, whatever) at application startup. You can also do it when loading a level (that's what all those loading screens in AAA games are doing). You can also do it in between every frame. You can even reload every model, then call a single draw of a single triangle, then reload every model again. Performance will definitely vary with each of those options.

 

When you are programming, the computer does whatever you tell it to do.

1

Share this post


Link to post
Share on other sites

Ok, Ill try. Fir;

 

>> there is a way of sending all meshes  at app startup and then sending only position matrices each frame?<<
 
Yes
 
>>if i upload a large vertex geometry in the frame and it resides in vram then it seem that before sendoing it next frame some api call deletes the prevoius in the vram.. is this true? what api call this is?<<
 
Immediate mode?
 
>>as to moving the vertices i do not want to move the vertices by updating the vertex array but just use glRotate glTranslate but then it is again whole vertex array sending (uploading)..<<
 

 

You can use glRotate/glTranslate without uploading the whole array using VBOs as everyone has been telling you.

 

>>. is this correct way of writing programs or this is bad way at all?<<

 

I believe its deprecated and you should use your own matrices. However, it does still work with glTranslate etc. 

1

Share this post


Link to post
Share on other sites

What you want is to do is use Vertex buffer objects (VBO) They store all your mesh data on the GPU until you explicitly destroy them and then do skeletal animation using the vertex shaders(GPU skinning) that way you only have to send transformation matrices for the bones each frame in order to animate the mesh.

1

Share this post


Link to post
Share on other sites

there is also subquestion of deleting the geometry data
- if i upload a large vertex geometry in the frame and it resides in vram then it seem that before sendoing it next frame some api call deletes the prevoius in the vram.. is this true? what api call this is?

If you do not store your vertex attributes in a VBO, the whole data will be moved from the system to the graphics card on every glDraw* call. After everything ordered in the glDraw* call has been rendered, the memory containing the data is immediately freed. The concept of 'frame' does not play into it and it's not really something that makes much sense in the context of modern OpenGL.
 

as to moving the vertices i do not want to move the vertices by updating the vertex array but just use glRotate glTranslate but then it is again whole vertex array sending (uploading)... is this correct way of writing programs or this is bad way at all?

As said repeatedly, static data which is rendered repeated is usually placed in a VBO. Using glRotatef, glTranslatef is no longer used in modern programs. That whole part of the API has been deprecated for good reasons. And while it's unlikely that your programs will stop working (at least on AMD or NVIDIA card) for the foreseeable future, you are artificially locking yourself out of new features, might end up on code paths that are less optimal than using the modern API and you are causing yourself more pain and inconvenience in the future (because the modern API has a bit more initial boilerplate code you need but is far simpler once that initial investment is done).
1

Share this post


Link to post
Share on other sites

What you want is to do is use Vertex buffer objects (VBO) They store all your mesh data on the GPU until you explicitly destroy them and then do skeletal animation using the vertex shaders(GPU skinning) that way you only have to send transformation matrices for the bones each frame in order to animate the mesh.

allright, this means that this vertex array way is deprecated?

0

Share this post


Link to post
Share on other sites

 

there is also subquestion of deleting the geometry data
- if i upload a large vertex geometry in the frame and it resides in vram then it seem that before sendoing it next frame some api call deletes the prevoius in the vram.. is this true? what api call this is?

If you do not store your vertex attributes in a VBO, the whole data will be moved from the system to the graphics card on every glDraw* call. After everything ordered in the glDraw* call has been rendered, the memory containing the data is immediately freed. The concept of 'frame' does not play into it and it's not really something that makes much sense in the context of modern OpenGL.
 

as to moving the vertices i do not want to move the vertices by updating the vertex array but just use glRotate glTranslate but then it is again whole vertex array sending (uploading)... is this correct way of writing programs or this is bad way at all?

As said repeatedly, static data which is rendered repeated is usually placed in a VBO. Using glRotatef, glTranslatef is no longer used in modern programs. That whole part of the API has been deprecated for good reasons. And while it's unlikely that your programs will stop working (at least on AMD or NVIDIA card) for the foreseeable future, you are artificially locking yourself out of new features, might end up on code paths that are less optimal than using the modern API and you are causing yourself more pain and inconvenience in the future (because the modern API has a bit more initial boilerplate code you need but is far simpler once that initial investment is done).

 

 

 

What you want is to do is use Vertex buffer objects (VBO) They store all your mesh data on the GPU until you explicitly destroy them and then do skeletal animation using the vertex shaders(GPU skinning) that way you only have to send transformation matrices for the bones each frame in order to animate the mesh.

 

 

allright this is usefull - i understand that there are two modes one does vram geometry clearing other preserves it

 

- though as to clearing i do not understand when it clears is it immediate, when some source triangle is just sent thru rendering its source data is freed immediate  or this is on some frame basis? (i understand you sy this is more immediate but i do not see it clearly, previously i suspected it was more like glFlush end of the frame)

 

- also i do not know how to sent the parameters to the whole big set of geometry data residing in vram - say it is by shaders, istn it very unhandy ? if you have scene that

contains a thousand of meshes need a thousand of parameters (position etc).. so

there is a thousand case switch in the shader which is reaching thousand times 

to cpu RAM memory to fetch this coordinates?

0

Share this post


Link to post
Share on other sites

If someone tells you how to do something (transfer data only once to GPU using OpenGL in this case), you can safely assume it is possible. You seem upset that nobody explicitly said it is possible, but I'm not sure what other conclusion could be reached. It is the reason I did not reply to the original post. I felt I could add nothing of value beyond what 3tatuk2 said.

 

You can load your textures and vertices (meshes, whatever) at application startup. You can also do it when loading a level (that's what all those loading screens in AAA games are doing). You can also do it in between every frame. You can even reload every model, then call a single draw of a single triangle, then reload every model again. Performance will definitely vary with each of those options.

 

When you are programming, the computer does whatever you tell it to do.

 

those first pseudo answer gioved nothing valuable to me.. i need to get and talk about some explanations and deeper topics not 10 seconds answers which i found more bad than helpfull so thay had subsero value for me personally, really

 

(as i said iam searchng for answer and some discussion, sadly get not to much time to go further now into opengl, maybe next year - but the later answers shows to be quite ok, tnx for later answers, now i feel i get it right - the  details then i can check in the future ;o)

Edited by fir
-2

Share this post


Link to post
Share on other sites
allright this is usefull - i understand that there are two modes one does vram geometry clearing other preserves it

 

Sort of. Vertex Arrays (not to be confused with Vertex Array Objects) are client-side, so the video driver has to reload the data on every call because you could have changed the contents since it is client-side.

 

 

- though as to clearing i do not understand when it clears is it immediate, when some source triangle is just sent thru rendering its source data is freed immediate  or this is on some frame basis? (i understand you sy this is more immediate but i do not see it clearly, previously i suspected it was more like glFlush end of the frame)

 

 

If you're talking about client-side vertex arrays, nothing gets cleared and your client-side memory does not get freed. He was probably talking about the video card's cache of your data being useless once the call finishes. Your client-side copy will have the same values for any attributes not modified by the glDraw*, and undefined values for any attributes modified.

 

- also i do not know how to sent the parameters to the whole big set of geometry data residing in vram - say it is by shaders, istn it very unhandy ? if you have scene that

contains a thousand of meshes need a thousand of parameters (position etc).. so

there is a thousand case switch in the shader which is reaching thousand times 
to cpu RAM memory to fetch this coordinates?

 

 

 

Shaders are the computational units of a GPU. Providing data to GPU computational units is quite handy, just like it's handy to provide data from system RAM to the CPU.

 

You can have thousands of meshes. You can use switch in the shaders if you want, but they're not going to fetch data from CPU RAM. If you want something from CPU RAM available to the shaders, you need to pass it over.

 

You'll specify how many vertices are going to be drawn (1 mesh, only part of a mesh, 10 meshes, whatever you choose), and the video card splits the vertices up and feeds them to the shaders. The video card might have thousands of shader units, so this will all be done in parallel.

Edited by richardurich
1

Share this post


Link to post
Share on other sites

 

 

- though as to clearing i do not understand when it clears is it immediate, when some source triangle is just sent thru rendering its source data is freed immediate  or this is on some frame basis? (i understand you sy this is more immediate but i do not see it clearly, previously i suspected it was more like glFlush end of the frame)

 

 

If you're talking about client-side vertex arrays, nothing gets cleared and your client-side memory does not get freed. He was probably talking about the video card's cache of your data being useless once the call finishes. Your client-side copy will have the same values for any attributes not modified by the glDraw*, and undefined values for any attributes modified.

 

 

no,no 

 

say i have 1MB (ram) vertex array containing some mesh (bunny or something)

 

i command it to draw on screen (i was using glDrawElements)

 

so this is being uploaded to vram, so now i got two copies of

it 1MB in ram and 1 MB in vram

 

then it is drawed, (I was never thinking on it to much yet but 

i see in my code that this procedure is repeated every frame

so it is near to obvoious that this vram copy is probably cleared 

each frame,

 

(this should be I think about the whole geometry data set send

this way in each frame - it must be cleared if this is constantly uploaded)

 

(*) [by this i mean the vram copy of this source geometry]

 

BitMaster said (confirmed) (that was helpful) this is cleared (*)-  i was suspecting that this is cleared, though i never heard when  is the moment where it is cleared (I suspected that maybe  this is at the end of the frame, I dont know glSwapBuffers of glflush something like that)

BitMaster said (if i understood) that it is cleared immediately

(like a stream) when gpu consumes it - this is also an option i think .. i dont know

 

You something about cache, (you probably call the thing i call here as a vram mesh copy as a cache) and i was also incidentally begin thinking now if there is maybe some cache mechanisms involved (because when i sent every frame a 1MB bunny vertex array which is not changing , it would be maybe theoretically possible that glDrawElements could reuse previous uploaded copy (you could probably sent a hint, that this is was

not changed - but this is probably not involved, as i understand

the mechanism called VBO is used here instead

 

so finally now some things seem cleared for me here, though 

maybe not all and if someone could share some more info yet

thanx for that 

Edited by fir
0

Share this post


Link to post
Share on other sites

so this is being uploaded to vram, so now i got two copies of
it 1MB in ram and 1 MB in vram

Actually you have three copies. When you call glDraw* the driver copies the data you gave it into system memory that belongs to the driver and schedules an upload to video memory. Then glDraw* returns and you are free to do whatever you want with the memory you gave to glDraw*.
Once the driver has finished uploading the data to the video card it can schedule rendering of the data. At this point the system memory copy can also be freed.
Once rendering of the data has happened the data in video memory is freed.

then it is drawed, (I was never thinking on it to much yet but 
i see in my code that this procedure is repeated every frame
so it is near to obvoious that this vram copy is probably cleared 
each frame,

Again, talking about 'frames' in the concept of modern OpenGL is pretty pointless. Things can be rendered to various framebuffers, the framebuffers can be used to render something else and some point down the line something is displayed to the user (or maybe not even that).
If you render the same mesh N times without the help of an VBO the same data will be uploaded N times to video memory, regardless of where you place your artificial frame points.

You something about cache, (you probably call the thing i call here as a vram mesh copy as a cache) and i was also incidentally begin thinking now if there is maybe some cache mechanisms involved (because when i sent every frame a 1MB bunny vertex array which is not changing , it would be maybe theoretically possible that glDrawElements could reuse previous uploaded copy (you could probably sent a hint, that this is was
not changed - but this is probably not involved, as i understand
the mechanism called VBO is used here instead

When you pass data without the aid of an VBO to a glDraw* call you implicitly tell the driver there is no point doing anything interesting with the data. It's throwaway data. If it's data worth keeping around the user would have put it into an VBO.
1

Share this post


Link to post
Share on other sites

(this should be I think about the whole geometry data set send

this way in each frame - it must be cleared if this is constantly uploaded)

 

(*) [by this i mean the vram copy of this source geometry]

 

BitMaster said (confirmed) (that was helpful) this is cleared (*)-  i was suspecting that this is cleared, though i never heard when  is the moment where it is cleared (I suspected that maybe  this is at the end of the frame, I dont know glSwapBuffers of glflush something like that)

BitMaster said (if i understood) that it is cleared immediately

(like a stream) when gpu consumes it - this is also an option i think .. i dont know

 

You something about cache, (you probably call the thing i call here as a vram mesh copy as a cache) and i was also incidentally begin thinking now if there is maybe some cache mechanisms involved (because when i sent every frame a 1MB bunny vertex array which is not changing , it would be maybe theoretically possible that glDrawElements could reuse previous uploaded copy (you could probably sent a hint, that this is was

not changed - but this is probably not involved, as i understand

the mechanism called VBO is used here instead

 

 

If you mean the video driver's copy (or copies) of the data is discarded when you say cleared, that's right. It never needs to be cleared though (memset to zero, zeromemory'd, calloc'd, etc.). I used the word cache to convey to you that the video driver recognizes the call as client-side memory and anything the driver uses will just be a cached copy. Think of it as cache marked as invalid for every other command. It was just a different way to look at the same thing in the hopes it made more sense to you.

 

Some vendors did provide functions to help avoid copying the memory around extra times. For example, Apple had GL_APPLE_vertex_array_range that let you promise not to touch the memory except as explained in the extension.

0

Share this post


Link to post
Share on other sites

 

then it is drawed, (I was never thinking on it to much yet but 
i see in my code that this procedure is repeated every frame
so it is near to obvoious that this vram copy is probably cleared 
each frame,

Again, talking about 'frames' in the concept of modern OpenGL is pretty pointless. Things can be rendered to various framebuffers, the framebuffers can be used to render something else and some point down the line something is displayed to the user (or maybe not even that).
If you render the same mesh N times without the help of an VBO the same data will be uploaded N times to video memory, regardless of where you place your artificial frame points.
 

well, ok 

though i am not accustomed to using non frame terminology,

physically you render frames 

if you do not use frames concept you mean something like

stream of images that could add to sum up images without any boundaries that it is finished... weird

 

for example you send buny than little house than some rocket

(to make of an image of bunny house and rocket, imo frame

is needed to say when you got result ready to draw and when

not yet 

 

(so i just doubt if it possible not to use frame concept in ogl, one need to know when frame is ready - and also need some 

notion of beggining the frame (need to clear it sometimes) - but do not matter )

Edited by fir
0

Share this post


Link to post
Share on other sites

 

 

there is also subquestion of deleting the geometry data
- if i upload a large vertex geometry in the frame and it resides in vram then it seem that before sendoing it next frame some api call deletes the prevoius in the vram.. is this true? what api call this is?

If you do not store your vertex attributes in a VBO, the whole data will be moved from the system to the graphics card on every glDraw* call. After everything ordered in the glDraw* call has been rendered, the memory containing the data is immediately freed. The concept of 'frame' does not play into it and it's not really something that makes much sense in the context of modern OpenGL.
 

as to moving the vertices i do not want to move the vertices by updating the vertex array but just use glRotate glTranslate but then it is again whole vertex array sending (uploading)... is this correct way of writing programs or this is bad way at all?

As said repeatedly, static data which is rendered repeated is usually placed in a VBO. Using glRotatef, glTranslatef is no longer used in modern programs. That whole part of the API has been deprecated for good reasons. And while it's unlikely that your programs will stop working (at least on AMD or NVIDIA card) for the foreseeable future, you are artificially locking yourself out of new features, might end up on code paths that are less optimal than using the modern API and you are causing yourself more pain and inconvenience in the future (because the modern API has a bit more initial boilerplate code you need but is far simpler once that initial investment is done).

 

 

 

What you want is to do is use Vertex buffer objects (VBO) They store all your mesh data on the GPU until you explicitly destroy them and then do skeletal animation using the vertex shaders(GPU skinning) that way you only have to send transformation matrices for the bones each frame in order to animate the mesh.

 

 

allright this is usefull - i understand that there are two modes one does vram geometry clearing other preserves it

 

- though as to clearing i do not understand when it clears is it immediate, when some source triangle is just sent thru rendering its source data is freed immediate  or this is on some frame basis? (i understand you sy this is more immediate but i do not see it clearly, previously i suspected it was more like glFlush end of the frame)

 

- also i do not know how to sent the parameters to the whole big set of geometry data residing in vram - say it is by shaders, istn it very unhandy ? if you have scene that

contains a thousand of meshes need a thousand of parameters (position etc).. so

there is a thousand case switch in the shader which is reaching thousand times 

to cpu RAM memory to fetch this coordinates?

 

 

These days everything is done by shaders, even if you use the fixed function pipeline, The driver provides basic shaders that mimic the way the old fixed functions worked), glTranslate, glRotate etc modify a matrix on the CPU and the driver will pass it to its stock shaders if you issue a draw call without using your own shaders.

 

This is worth reading: http://classes.soe.ucsc.edu/cmps162/Spring12/s12/labnotes/shaders.html

2

Share this post


Link to post
Share on other sites

 

These days everything is done by shaders, even if you use the fixed function pipeline, The driver provides basic shaders that mimic the way the old fixed functions worked), glTranslate, glRotate etc modify a matrix on the CPU and the driver will pass it to its stock shaders if you issue a draw call without using your own shaders.

 

This is worth reading: http://classes.soe.ucsc.edu/cmps162/Spring12/s12/labnotes/shaders.html

 

 

well i can say that i am not learning it because i find all this

ugly and i just seem to not like it - though I must say some

game graphics achived by this are quite impressive - maybe i will start some topic on this becaouse Im curious for opinions 

if this opinion is only my own

-1

Share this post


Link to post
Share on other sites


well i can say that i am not learning it because i find all this

ugly and i just seem to not like it - though I must say some

game graphics achived by this are quite impressive - maybe i will start some topic on this becaouse Im curious for opinions

if this opinion is only my own

 

Well, if you dont like shaders, no one is forcing you, you can still use the old opengl fixed pipeline if you wish.

 


well, ok

though i am not accustomed to using non frame terminology,

physically you render frames

if you do not use frames concept you mean something like

stream of images that could add to sum up images without any boundaries that it is finished... weird



for example you send buny than little house than some rocket

(to make of an image of bunny house and rocket, imo frame

is needed to say when you got result ready to draw and when

not yet

(so i just doubt if it possible not to use frame concept in ogl, one need to know when frame is ready - and also need some

notion of beggining the frame (need to clear it sometimes) - but do not matter )

 

I dont see the problem here. In opengl, you (usually) start a drawing a frame using something like glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT), (flags depend on what buffers you use, for example, the depth buffer is not needed in 2d, and you could use the flag GL_STENCIL_BUFFER_BIT to clear the stencil buffer if you're using it), then, you finish drawing by calling SwapBuffers(), which draw the backbuffer to the screen, assuming you're using double buffering., if not, i beleive you should call glFinish() (someone correct me if im wrong on that one).

 

Like many others have told you before, you usually try to avoid resending the same vertices to opengl every frame, since that's a huge performance hit. However, if you only need to draw a few vertices, that dosen't matter much imo. Also, about that copy in ram, once your done uploading the vbo to the gpu, it's ok to free the memory in ram, you probably (at least, in 99% of the cases) wont need it anymore.

1

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0

  • Similar Content

    • By mapra99
      Hello

      I am working on a recent project and I have been learning how to code in C# using OpenGL libraries for some graphics. I have achieved some quite interesting things using TAO Framework writing in Console Applications, creating a GLUT Window. But my problem now is that I need to incorporate the Graphics in a Windows Form so I can relate the objects that I render with some .NET Controls.

      To deal with this problem, I have seen in some forums that it's better to use OpenTK instead of TAO Framework, so I can use the glControl that OpenTK libraries offer. However, I haven't found complete articles, tutorials or source codes that help using the glControl or that may insert me into de OpenTK functions. Would somebody please share in this forum some links or files where I can find good documentation about this topic? Or may I use another library different of OpenTK?

      Thanks!
    • By Solid_Spy
      Hello, I have been working on SH Irradiance map rendering, and I have been using a GLSL pixel shader to render SH irradiance to 2D irradiance maps for my static objects. I already have it working with 9 3D textures so far for the first 9 SH functions.
      In my GLSL shader, I have to send in 9 SH Coefficient 3D Texures that use RGBA8 as a pixel format. RGB being used for the coefficients for red, green, and blue, and the A for checking if the voxel is in use (for the 3D texture solidification shader to prevent bleeding).
      My problem is, I want to knock this number of textures down to something like 4 or 5. Getting even lower would be a godsend. This is because I eventually plan on adding more SH Coefficient 3D Textures for other parts of the game map (such as inside rooms, as opposed to the outside), to circumvent irradiance probe bleeding between rooms separated by walls. I don't want to reach the 32 texture limit too soon. Also, I figure that it would be a LOT faster.
      Is there a way I could, say, store 2 sets of SH Coefficients for 2 SH functions inside a texture with RGBA16 pixels? If so, how would I extract them from inside GLSL? Let me know if you have any suggestions ^^.
    • By KarimIO
      EDIT: I thought this was restricted to Attribute-Created GL contexts, but it isn't, so I rewrote the post.
      Hey guys, whenever I call SwapBuffers(hDC), I get a crash, and I get a "Too many posts were made to a semaphore." from Windows as I call SwapBuffers. What could be the cause of this?
      Update: No crash occurs if I don't draw, just clear and swap.
      static PIXELFORMATDESCRIPTOR pfd = // pfd Tells Windows How We Want Things To Be { sizeof(PIXELFORMATDESCRIPTOR), // Size Of This Pixel Format Descriptor 1, // Version Number PFD_DRAW_TO_WINDOW | // Format Must Support Window PFD_SUPPORT_OPENGL | // Format Must Support OpenGL PFD_DOUBLEBUFFER, // Must Support Double Buffering PFD_TYPE_RGBA, // Request An RGBA Format 32, // Select Our Color Depth 0, 0, 0, 0, 0, 0, // Color Bits Ignored 0, // No Alpha Buffer 0, // Shift Bit Ignored 0, // No Accumulation Buffer 0, 0, 0, 0, // Accumulation Bits Ignored 24, // 24Bit Z-Buffer (Depth Buffer) 0, // No Stencil Buffer 0, // No Auxiliary Buffer PFD_MAIN_PLANE, // Main Drawing Layer 0, // Reserved 0, 0, 0 // Layer Masks Ignored }; if (!(hDC = GetDC(windowHandle))) return false; unsigned int PixelFormat; if (!(PixelFormat = ChoosePixelFormat(hDC, &pfd))) return false; if (!SetPixelFormat(hDC, PixelFormat, &pfd)) return false; hRC = wglCreateContext(hDC); if (!hRC) { std::cout << "wglCreateContext Failed!\n"; return false; } if (wglMakeCurrent(hDC, hRC) == NULL) { std::cout << "Make Context Current Second Failed!\n"; return false; } ... // OGL Buffer Initialization glClear(GL_DEPTH_BUFFER_BIT | GL_COLOR_BUFFER_BIT); glBindVertexArray(vao); glUseProgram(myprogram); glDrawElements(GL_TRIANGLES, indexCount, GL_UNSIGNED_SHORT, (void *)indexStart); SwapBuffers(GetDC(window_handle));  
    • By Tchom
      Hey devs!
       
      I've been working on a OpenGL ES 2.0 android engine and I have begun implementing some simple (point) lighting. I had something fairly simple working, so I tried to get fancy and added color-tinting light. And it works great... with only one or two lights. Any more than that, the application drops about 15 frames per light added (my ideal is at least 4 or 5). I know implementing lighting is expensive, I just didn't think it was that expensive. I'm fairly new to the world of OpenGL and GLSL, so there is a good chance I've written some crappy shader code. If anyone had any feedback or tips on how I can optimize this code, please let me know.
       
      Vertex Shader
      uniform mat4 u_MVPMatrix; uniform mat4 u_MVMatrix; attribute vec4 a_Position; attribute vec3 a_Normal; attribute vec2 a_TexCoordinate; varying vec3 v_Position; varying vec3 v_Normal; varying vec2 v_TexCoordinate; void main() { v_Position = vec3(u_MVMatrix * a_Position); v_TexCoordinate = a_TexCoordinate; v_Normal = vec3(u_MVMatrix * vec4(a_Normal, 0.0)); gl_Position = u_MVPMatrix * a_Position; } Fragment Shader
      precision mediump float; uniform vec4 u_LightPos["+numLights+"]; uniform vec4 u_LightColours["+numLights+"]; uniform float u_LightPower["+numLights+"]; uniform sampler2D u_Texture; varying vec3 v_Position; varying vec3 v_Normal; varying vec2 v_TexCoordinate; void main() { gl_FragColor = (texture2D(u_Texture, v_TexCoordinate)); float diffuse = 0.0; vec4 colourSum = vec4(1.0); for (int i = 0; i < "+numLights+"; i++) { vec3 toPointLight = vec3(u_LightPos[i]); float distance = length(toPointLight - v_Position); vec3 lightVector = normalize(toPointLight - v_Position); float diffuseDiff = 0.0; // The diffuse difference contributed from current light diffuseDiff = max(dot(v_Normal, lightVector), 0.0); diffuseDiff = diffuseDiff * (1.0 / (1.0 + ((1.0-u_LightPower[i])* distance * distance))); //Determine attenuatio diffuse += diffuseDiff; gl_FragColor.rgb *= vec3(1.0) / ((vec3(1.0) + ((vec3(1.0) - vec3(u_LightColours[i]))*diffuseDiff))); //The expensive part } diffuse += 0.1; //Add ambient light gl_FragColor.rgb *= diffuse; } Am I making any rookie mistakes? Or am I just being unrealistic about what I can do? Thanks in advance
    • By yahiko00
      Hi,
      Not sure to post at the right place, if not, please forgive me...
      For a game project I am working on, I would like to implement a 2D starfield as a background.
      I do not want to deal with static tiles, since I plan to slowly animate the starfield. So, I am trying to figure out how to generate a random starfield for the entire map.
      I feel that using a uniform distribution for the stars will not do the trick. Instead I would like something similar to the screenshot below, taken from the game Star Wars: Empire At War (all credits to Lucasfilm, Disney, and so on...).

      Is there someone who could have an idea of a distribution which could result in such a starfield?
      Any insight would be appreciated
  • Popular Now