Skip to main content
gamedev.net
🔒 Locked

My rendering system.

Started by bzroom May 16, 2004 at 7:55 PM 1 replies 1k views
Original Post
bzroom
bzroom
My rendering system concept. The interface will be a class called cRenderer containing the following functions. LoadMaterial - This function will load a specified material file and return a handle to it. (Details of the material file below.) UnloadMaterial - Takes a material handle and decrements its refernce count. If its zero it is deleted. This can be disabled if you know the material will be reloaded later in the scene, to optimize in-game loading. ClearMaterials - Deletes all the materials no matter what. Not important. RegisterGeometry - This takes a struct of pointers to geometry data, matrix pointer, and a material handle and adds it to the geometry list. SetGeometryLock - Sets wether the geometory is "locked" as in its drawn every frame. (Don't know how or if I will support this. VBO's) BeginScene - This clears the render graph. ProcessScene - This travels the render graph and renders each geometry chunk. Everything will be loaded in list objects that only load something once. If it exists it returns its index in the list. The object can be accesed like listobject[listindex]->Whatever proterty. The list objects are template classes for the object they manageing. A material is actualy made up of few parts. Each material contains list of parameters to control the materia, and a list of passes. Each pass will contain a shader, and list api states. Each shader will contain a list of parameters, and either a hardware shader, or a software shader (Vertex only). The shader file will list fall backs if they exist for each shader. Starting from the highest support required it loades the code of the highest shader supported. If its software vertex shader, it links a dll and get the address of the shader function. The list of parameters will be the same for the hardware and software shaders. So to the passes the shader will always appear the same. If no shader is supported and the material is dependent, the material will be disabled and the loading function will return that. It will be up to the loading object to take action if a required shader is not supported (such as automaticaly disable fog). The material files will contain, all the hardware shaders code (for differnt support levels), the api states, and the name of the dll for software shaders. If a software shader is needed it will be in a seperate dll file. (maybe eventualy combine them). In order for something to be drawn it must be registered with the shader. This puts the required material, if not already, in the render graph. The materials are sorted first by shader, then by passes, then by individual settings (such as diffuse color or texture id). Each material in the graph will be parent to a list of geomtry id's to render (they will all be stored in a list object). Everyframe the shader will be told to process its list in this fashion. loaded materials are
mat1
	pass1 
		render to texture id 5
		shader1
		drawgeometry
	pass2
		render to frame buffers
		shader2
		drawscreenquad

mat2
	pass3
		render to frame buggers
		shader1
		drawgeometry

  
Render graph
		
set shader 1
	set pass1
		set mat1
      			if pass1.drawgeometry
        			draw chunk1
        			draw chunk2
			else
				drawscreenquad

set shader2
	set pass2
		set mat1
			if pass2.drawgeometry
				drawchunk3
			else
				drawscreenquad
		 
   
Sorry I'm not very good at writing down how I imagine things, I have a pritty good start on it and writing this has helped me understand what I'm thinking of. Now for input. I get a little confused when I think about multiple passes. Because each pass may require differnt shaders it will be sorted by shader. Lets say we have a glowing material. The first pass will render the geometry to a texture with some basic shaders. The second pass will render that texture over the screen with a blur pixel shader. Would this every be a problem, would I ever have to do like:
Material 1
	pass1
		shader 1
	pass2
		shader 2

maerial 2
	pass3
		shader 1
   
I never want to switch into the same shader twice (as I assume this is the slowest material change). edit: I realize I will have to order things like alphablending too. I will have to reload shaders possibly when I get the alphablending list. The draw me last always list. Any questions or suggestions? [edited by - honayboyz on May 16, 2004 8:57:18 PM] [edited by - honayboyz on May 16, 2004 8:59:58 PM] [edited by - honayboyz on May 16, 2004 9:04:12 PM]
hplus0603
hplus0603
I''d make the shader to use part of the material, so when you register the geometry/state/parameters data, it magically goes into the right shader(s) for its pass(es).

Anyway, implement it. There''s no better way to learn the specifics of what you''re doing!
enum Bool { True, False, FileNotFound };
bzroom
bzroom
quote:
Original post by hplus0603
I''d make the shader to use part of the material, so when you register the geometry/state/parameters data, it magically goes into the right shader(s) for its pass(es).




The materials will be set up like this.


Material
{
geomtrylist
passes
{
shader
}
}


When you register a chunk of data it will basicaly be like:


bool Register(chunkdata *Data)
{
return materials[data->matid].geometrylist.add(data);
}


The graph will be elsewhere consisting of only pointers. Since everything will be in index lists assigning data will be very "magical".

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.

Sign in to reply to this topic.