   Transform Expense vs State Change Expense
  I am working on a game and I had an idea to optimise state changes. I made a class to represent a material, containing the color texture and the state changes requires ie (DEPTHTEST | ALPHABLEND etc). These material classes are stored on a binary tree where each level is a different state. To render I parse the tree and set states as I go through the tree, each leaf node has a list of materials using that state setup, then each mesh using that material is rendered.This was fine until I realised that somewhere in there i need to transform the mesh. example:If I have a car, with a diferent material and mesh for the body, windows, and wheels I would end up with a tree similar to the one below:   BLENDING   / \   off /   \ on /\ DEPTH TEST   DEPTH TEST    /\  /\    off /  \ on   off /  \ on Body Windows Wheels ... etc  now when i render I will have to load a matrix and render the body, then load another matrix for the wheels, and then load the same matrix again when I render the window.Now my question is, would I gain more by grouping objects by transforms (to minimise matrix loads/multiplication), or by grouping objects by material (to minimise state changes)? Alex Walters 
  minimise state changes, as those are genearly the most expensive operations you can dogeometrey processing is very fast on todays hardware, chances are you''ll become fill rate bound before you have to worry too much about your transform rate ;  Is a single state change more expensive than the extra matrix maths i would need to perform and the extra matrices i will need to store? I suppose it depends on what I am rendering, Its going to be rendering a terrain, some tanks, units, particles. In essence there will probably be upto about 20 materials in a full scene and maybe maximum of 100 or so units.that would be either 20 material changes (@ 6 states per material = 120 state changes) and 200 matrix loads (working on the assumption of 2 material/mesh pairs per object) OR 100 matrix loads and 100 material changes (600 state changes) if grouped by transform.I guess that gives me my answer!!! that is a pretty rough example. In fact the first example would be a lot less than 120 state changes because the materials are grouped by there requires states. I calculated that based on a system of 6 states, Alpha blend, Depth testing, alpha testing, depth buffer locking, texturing and lighting there will be an absolute worst-case scenario of 128 state changes. The worst-case is that every posible combination of states is used.Thats not too bad!!!;  i dare say a matrix load is no where near as hard on the hardware as a state change, as i would guess the matrix load is performed and held ''on chip'' where as state changes genearly have to access vram, thus why you should keep state changes down ;  Off subject -Just out of interest phantom, how long have you been programming OpenGl? you definitely seem to know your stuff, Ive seen alot of your posts around! Ive been a member for ages but I havent posted alot. What sort of games/demo's/etc have you coded?Thought I would look at your website, turns out you do pretty much the same as me [sleep!], and I live fairly close in Colchester! Blimey its a small world!   [edited by - aleks_1661 on February 8, 2004 8:32:09 PM];  I''ve been programming with OpenGL from around 2000ish, although i''ve never really done all that much with it, i''m more of a theorical programmer when it comes to it, ie i know the syntax and what should happen from alot of reading, when implimentations dont do as they should it does throw a slight curve for me, but you learn to adjust I was planning to do some major openGL stuff last year, but big work project appeared and i''ve not had the time of late and i''ve been working on improving my C++ skills as atm is more relivent to my job When i finaly get something worth showing out you''ll all know about it 