• Content count

  • Joined

  • Last visited

Community Reputation

221 Neutral

About melbow

  • Rank
  1. I'm using Chrome for iPhone and when I quote someone it places the HTML in the reply, but as text and not as HTML. Additionally, when then editing a post with HTML in it, the HTML is duplicated. Lastly, I suggest placing a "To Bottom of Page" button at the top of the mobile site when viewing a post, because having to manually scroll to the bottom every time using the phone is pretty annoying.
  2. OpenGL Always use VAO or no?

    OFF TOPIC: And desperately needs to update the mobile site. It has some very annoying design flaws and bugs...
  3. OpenGL Always use VAO or no?

    <blockquote class='ipsBlockquote'data-author="Aks9" data-cid="5022808" data-time="1358498689"><p> <blockquote class='ipsBlockquote'data-author="melbow" data-cid="5022767" data-time="1358482777"><p>I'm sure there has to be a similar thread somewhere, but I can't find it. I was wondering, is there any reason not to use a VAO? And in the latest version of OpenGL, are all other forms of rendering deprecated?</p></blockquote> <br /> In core profile VAO is mandatory. But it can be created, selected and forgotten. It is the way I'm using VAO. <span rel='lightbox'><img src='' alt='Posted Image' class='bbc_img' /></span><br /> VAO is not always the best way to do things. Try to make several VAOs and select them and compare to changing just one attribute in a single VAO. If you have to change many attributes at once, than just selecting a VAO is better. For a single attribute, or few of them... hm, I wouldn't bet. Also, mixing VAO and NVIDIA bindless is not a good idea.</p></blockquote> Thank you! That is exactly what I needed to know.
  4. OpenGL Always use VAO or no?

    Thanks Irreversible. I know fixed-function is dead (as it should be), but wasn't sure if there was some scenerio where it might be better to call glVertexAttribPointer and not use a vertex array object. I'm writing a wrapper for GL ES (for educational as well as practical applications) and was considering forcing the usage of VAOs. I guess I will go ahead with my plan then. Thanks again.
  5. I'm sure there has to be a similar thread somewhere, but I can't find it. I was wondering, is there any reason not to use a VAO? And in the latest version of OpenGL, are all other forms of rendering deprecated?
  6. Advanced Render Queue API

    So I think I've managed to go full circle from virtual Draw methods to a Render Command Queue back to virtual Draw methods. It just doesn't seem worth it to do all this work just for a unified renderer when you could have a virtual Draw method and call it a day. If renderable objects are managed and batched prior to being made into RenderItems then as far as I can tell, you could just give the batch a Draw method and enqueue the batch. I guess I don't really see the point of the Commands. I am at a loss because I want to do this the right way, but I have too little experience with coding rendering APIs to know what that is. And please don't say, "There is no 'right way.'" Could anybody recommend a book that covers render queues similar to what has been described by Hodgman?
  7. Advanced Render Queue API

    Is the reason for storing StateGroups as a header and chunk of States that you make it more cache friendly due to locality? Also, you say you store StateGroups in Resources. Am I correct in assuming some StateGroups must still be created at runtime, e.g. geometry instance transforms. And therefore RenderItems creation also cannot be done when the game object is initialized, but must be done every frame. Is this correct or am I completely off base?
  8. Advanced Render Queue API

    While I am not Hodgman, I will say that, broadly speaking, templates increase the compiled code's size. If the function is inline though (which I assume it is in your case, TiagoCosta), there should not be any negative performance penalties.
  9. Advanced Render Queue API

    Thanks again Hodgman. I really appreciate how detailed yet concise your responses are. The only thing that is still not completely clear to me is the generation of RenderItems. Are they allocated each frame from a data cache (like what is described here )? And would a higher level object like a GLShader or GeometryPacket class then maintain their respective Commands? I am not seeing a way to to check for duplicate states by comparing pointers unless the Commands are maintained by global, shared resources, or I guess if Commands ARE global shared resources, but the first option seems cleaner. Again, I really appreciate everyone's input on this thread, it has helped me a great deal.
  10. Advanced Render Queue API

    I too am puzzled by how redundant state changes are eliminated in this model. Am I correct in that states may be submitted in any order? And if this is the case, then states may be sorted and then linearly compared. However, this seems expensive considering how many states may be set per frame. I'm sure you have a much more clever way of doing this.
  11. Advanced Render Queue API

    All this talk of unpredictable behavior has me questioning this approach. What if a Command was simply a sort of container, like: struct Command { Commands::Type id; union { Foo* foo; Bar* bar; } u; };
  12. Advanced Render Queue API

      So if everything is a command, do you batch ahead of time like Noizex? Say for example, geometry instancing, how would you collect each instance for creation of the commands? And thanks for such a good example. You've helped clarify a ton already :D
  13. Advanced Render Queue API

    Hodgman, are your states then inheritted from a State base class? If not, how do you determine how to set the state the correct way? I would think you would want to avoid the overhead of virtual functions on something so low level on the engine.
  14. Advanced Render Queue API

    Thanks for replying Noizex. You gave some great input. I was wondering if you perform any batching of your Render Tasks and if so, how? I don't see any place for attributes that aren't in your VAO.
  15. Let me preface this by saying I have read everything I could find on the web on this topic, but have been unable to answer my question. This list includes most notably: I understand sorting the draw calls and how to use this system under the fixed-function pipeline. However, when I change to a programmable pipeline, I can't seem to come up with how a "Render Operation" would be structured.   The best solution I could come up with was an object list for both uniforms and attributes. However, I can't see how a VAO or VBO would fit into this scheme.   Roughly, my code might look like: class ShaderProgram { public: void Create(char*,char*); void MakeCurrent(); ShaderAttributeInfo const & GetAttribute(const char* name); ... private: List<ShaderAttributeInfo> m_Attributes; List<ShaderUniformInfo> m_Uniforms; }; class ShaderAttribInfo { GLint handle; GLenum type; public: Set(void* data); }; class ShaderAttrib { ShaderAttribInfo* info; void* data; ... }; ... // Same basic structure for Uniforms class RenderOperation { List<ShaderAttrib> m_Attributes; List<ShaderUniform> m_Uniforms; ShaderProgram* m_Program; };   I'm trying to make my system as versatile, yet efficient as possible.   To reiterate, my question is: How would a "Render Operation" be formatted for a Render Queue using a programmable pipeline? The operation should allow for any sort of uniform or attribute and allow for VAOs and VBOs. And I don't feel the need to support a fixed function pipeline, so don't worry about that.   I hope I made my confusion clear enough. Thanks a ton.