3D Help with Deferred Rendering

You didn't discribe what's wrong/not working?
I put a picture in the post, as it explains the issue perfectly. The light isn't smoothing as it is in your example project, despite the code being exactly the same. I can see a difference in the light render target, in which is isn't rendering the geometry which isn't lit, as it does in yours.

The textures also render with really high contrast, again testing with your textures.

Specular highlights also aren't working, it just replaces the diffuse texture with the white parts of the specular texture.

Thanks, wasn't expecting you to be around anymore
- TSB
 
O

orange451

Guest
The main rule about deferred renderers: Build your game around the renderer, don't build the renderer around your game.

There could be millions of things wrong with your project. Your GBuffer looks more-or-less correct, so your problem lies somewhere with how you are calculating the light.

It is impossible to tell exactly without your source code.
 
The main rule about deferred renderers: Build your game around the renderer, don't build the renderer around your game.

The source code hasn't changed much from xygthop3's original one:
http://imgur.com/a/JOXoD

The renderer was built into the game after starting, but there's no gameplay functions which would get in the way of it working correctly. Textures are PNG, loaded externally, models are a custom format stored in binary, loaded into a vertex buffer with Position, Normal, Texcoord and Colour support.

I've never had this much trouble before, and I really want to use this particular renderer as opposed to another, it's really damn fast due to the MRT support.
 

xygthop3

Member
I put a picture in the post, as it explains the issue perfectly.
I can see the black lines but it doesn't explain anything perfectly.

Thanks, wasn't expecting you to be around anymore
Geeesss......thanks, I'm 35 and I'm not dead yet.........lucky me I guess.

The main rule about deferred renderers: Build your game around the renderer, don't build the renderer around your game.
This is exactly right, I would never try to implement this type of render half way through making a game.

But anyways, looks like you're using a pretty old version of the Deferred Redner so can I suggest that the first thing you do is start using the latest version from the Marketplace https://marketplace.yoyogames.com/assets/2157/deferred-rendering
Then if you could describe the issue(s) you're having and maybe post an exe at least so we can see the issue in action?
 
Geeesss......thanks, I'm 35 and I'm not dead yet.........lucky me I guess.
Hehe, no insult meant, I was merely referring to the forum change, and the fact I could've sworn I heard you left Game Maker for other methods a while ago.

That's the version I'm using, the one where specular mapping and normal mapping are combined. The black lines are supposed to be there, that's a gird I've implemented so I can position objects easier.

The main issue here is that you can clearly see the sphere that's used to light the room. I've tried a few different things, such as turning culling off while rendering the sphere, but it never changes.

The problem has actually gotten worse because I've been fiddling around with it for the past few hours, now anything outside the sphere is totally black, so the ambient lighting has clonked out.

I've explain the other issues in a post above, I've got ZIP of the game uploading now, I'll attach it when it's done.

EDIT: Game here: https://www.mediafire.com/?60pafcf621516xa
 

xygthop3

Member
From what I can tell it looks like you've only rendered up to the scr_deferred_draw() which is why its only showing the light and high contrast (in the draw event) and you've forgotten the scr_deferred_final_pass() in the Draw GUI event.
 

xygthop3

Member
You can if you want.

Are you drawing the lights using the point_light_vertex_buffer? as its a specific inside out sphere with the normals facing towards the center of the sphere.
 
You can if you want.

Are you drawing the lights using the point_light_vertex_buffer? as its a specific inside out sphere with the normals facing towards the center of the sphere.
Yeah, I'm using it. Project file is here: http://www.mediafire.com/file/8q3ib7iw5w78l1r/Proj_RadishEdition.gmx.zip
I'm 100% betting I'm being a moron and forgetting something really important, but I doubt it. I've been checking over the code for the past two days, it's the entire reason I resorted to asking for help.
 

xygthop3

Member
I'm getting a lot of errors and things aren't opening correctly from the gmx, could you please export the project as a .gmz ?
 

xygthop3

Member
Okay, that took some effort to find the issue because you've hacked the deferred scripts to bits and added your own. I'm not saying that you shouldn't do this but you need to be careful and check what my scripts were doing before you make your own to do basically the same thing.

MAE_LightPointCreate() is the culprit, shaders only handle colour ranges from 0-1 and you're passing 0-255. (you will want to change this for MAE_LightPointUpdate() too)
You have:
Code:
global.__MALIGHT[argument0].r = colour_get_red(argument5);
global.__MALIGHT[argument0].g = colour_get_green(argument5);
global.__MALIGHT[argument0].b = colour_get_blue(argument5);
And it should be:
Code:
global.__MALIGHT[argument0].r = colour_get_red(argument5)/255;
global.__MALIGHT[argument0].g = colour_get_green(argument5)/255;
global.__MALIGHT[argument0].b = colour_get_blue(argument5)/255;
Also, any object that is passed into the deferred render eg: camera, lights, levels, models should all have the "Visible" box unchecked, this is because the controller object is performing the draw events when the correct surface is currently being drawn too so there is no need to have these objects (other than the controller object that's drawing to the surfaces) visible at any time. I unchecked these in your game and the FPS went from ~500 to ~800 so its defiantly worth the effort.

Good luck with your game.
 
I can't believe I was that stupid man, had to just slap myself. This is why I have to learn about HLSL, I thought it could accept values of 0 - 255, unlike the ASM Shaders Ultimate3D used to use. Thank you so much.
 
Top