GDR Forum Index
Podcast Podcast
Dev Dev Logs
Search Search
RSS RSS
Register Register
Log in Log in
Reply to topic GDR Forum Index -> Game Developer's Refuge -> Development Log - Mutiny Engine Page Previous  1, 2, 3 ... 13, 14, 15
View previous topic :: View next topic  
Author Message
Gil
Developer

Joined: 14 Nov 2005
Posts: 2341
Location: Belgium
PostPosted: Wed Jul 10, 2013 9:03 am    Post subject: Reply with quote

Alex wrote:
I don't know much about these things, but perhaps there's a way to add some sort of dust mask thing that dulls the effects in random areas.. Having surfaces look too uniform in any kind of way can be a bit odd.
Procedurally generated noise/blur overlays for the specular map is probably what you mean. Sounds interesting :)

Can probably do that in a shader of some sort, and it's probably possible to cache it
_________________
PoV: I had to wear pants today. Fo shame!
View user's profile Send private message Visit poster's website
Bean
Admin

Joined: 20 Aug 2005
Posts: 3772

PostPosted: Wed Jul 10, 2013 7:26 pm    Post subject: Reply with quote

These days light and shadow can be used to great effect in hiding the fact that you're looking at the same texture(s). That's not a real solution but it does keep things somewhat interesting. Perhaps I'll think up some method.

As for bricks, Diversion has many! I was about half way done working on the maps for them when I realized I had a water leak in my home. Obviously that promptly put things on hold for the evening. I have since fixed the leak though so now I'm getting back at it. Perhaps tomorrow I'll have a screenshot.

-Bean
_________________
Kevin Reems | Nuclear Playground | Solid Driver
View user's profile Send private message Visit poster's website
Bean
Admin

Joined: 20 Aug 2005
Posts: 3772

PostPosted: Thu Jul 11, 2013 1:21 am    Post subject: Reply with quote

Here are some bricks.


I've remade these and the shader code a billion times trying to dial in the best way to do both. In the end the day, my shader ended up exactly as it was 24 hours ago. I've learned a lot though, not just about the code but how to effectively make the maps in conjunction with normal maps. It's very easy to go overboard with both of these!

My shader still has room for improvement though. Click here to see the insanity one can take this stuff. For speed reasons alone I don't intend to pull off what you'll see on the right.
Also I don't think my bricks fully showcase my shader in it's current state. But those walls are suppose to be cinder block and not the wonky bricking with the huge gaps you usually see when you think of parallax mapping.


-Bean
_________________
Kevin Reems | Nuclear Playground | Solid Driver
View user's profile Send private message Visit poster's website
Bean
Admin

Joined: 20 Aug 2005
Posts: 3772

PostPosted: Sat Jul 20, 2013 7:38 pm    Post subject: Reply with quote

Woo! Thanks to this reference on PNG files I was finally able to grab the number of channels in my texture files. DirectX10 will tell you every PNG file is RGBA and I didn't want to use a lib for something so simple. And indeed it is simple. You just have to know which byte to read to get the info.

This not only allows Mutiny to select the best texture format for the image but also determines what shaders are ran.
e.g. Blindly allowing DirectX to load a PNG without an alpha channel results in and RGBA texture with an all white Alpha. Typically this is a safe default but if you've got a pixel shader that runs parallax mapping on any normal map with an alpha channel you end up doing a bunch of processing for nothing!

As of now, Mutiny can take DDS and PNG files and either way the data will end up in the most efficient format.
Originally I had switched all of my files over to DDS but I've found the compression can leave a lot to be desired depending on the imagery. Especially so with normal maps. So now I try everything in DDS but if it sucks for some reason I re-save it as PNG (All source files are PSD). Sometimes the issue is image quality and other times it's file size. Depending on the imagery DDS files can be bigger or smaller than PNG files (and I'm not even storing MIP Maps in the files).

So I'm sure that was an incredibly boring read. Sorry about that!


-Bean
_________________
Kevin Reems | Nuclear Playground | Solid Driver
View user's profile Send private message Visit poster's website
Bean
Admin

Joined: 20 Aug 2005
Posts: 3772

PostPosted: Thu Jul 25, 2013 10:18 pm    Post subject: Reply with quote

So my new shaders allow me to throw lights around like an LSD addict. Then I noticed things were hitting their max light limit when they shouldn't have. Turned out my culling code for my spot lights was shit. When I looked at it, I even had a comment telling me that it was shit hehe

I did some research on the math involved to see if a sphere is within a cone. Turns out it's pretty involved and CPU heavy. Then I looked into how other people do it since this isn't exactly a new problem in the graphics world. Turns out people use frustum culling as it's very fast and accurate enough for the task. Luckily I'm already doing frustum culling for the camera and the obstruction optimization I did awhile back.
Now I've got it working for my spotlights as well. This probably added a slight performance gain but more importantly I can throw around more spotlights without them conflicting with each other when they shouldn't.

I'm hoping to post some new screenshots in the next week or two. Diversion's looking a lot better while adding minimal assets to do so.
Even moreso I'm looking forward to finishing Diversion and making something new that takes better advantage of Mutiny.


-Bean
_________________
Kevin Reems | Nuclear Playground | Solid Driver
View user's profile Send private message Visit poster's website
Bean
Admin

Joined: 20 Aug 2005
Posts: 3772

PostPosted: Fri Aug 02, 2013 11:34 pm    Post subject: Reply with quote



Added a new feature to Build Mode to make it easier to see what the lights are up to. Each of the green circles shows a light's range. Near the bottom there you can see an object I have selected. The red circle is the object's radius. The white lines point to each light that is affecting that object.

This is all good info for determining if I've got too many lights in one area. It also makes it obvious if there's a bug. Right away I found some objects that had their radius set to nearly double what they should have been. This caused those objects to trigger lights that weren't even in range. Probably screwed up culling and slowed down collision detection too.

Most of my work the past week or two have been with Diversion. Every once in awhile I've gotta muck with the engine though.


-Bean
_________________
Kevin Reems | Nuclear Playground | Solid Driver


Edited by Bean on Tue Aug 27, 2013 10:02 am; edited 2 times
View user's profile Send private message Visit poster's website
Bean
Admin

Joined: 20 Aug 2005
Posts: 3772

PostPosted: Tue Aug 27, 2013 12:05 am    Post subject: Reply with quote

Here's some parallax+normal mapping. Click the images to enlarge.


This was actually a great deal of work. It started in a grocery store where I took a photo of some apples. I then had to do the usual photoshoping to make it tile cleanly, remove the stickers on each apple etc. Where it gets interesting is with lighting.
I actually had to remove the various lighting highlights on each apple since the shader would recreate these. That became the color map (a.k.a. Diffuse Map). I then created height and normal maps.
All of the apples in this shot are on a single quad. The depth, shadows, and lighting seen here are shader generated.


Here's another example of the parallax mapping. You may need to click the image to see the full effect. All of the keys are perspective correct as you pan around.

That code's actually been complete for awhile but these were the first images that really show it off.
Aside from that, I've been knocking out bugs, cleaning things up etc.
I added a new option for texture compression which can be None, Auto or All textures. Auto is the default and simply keeps textures compressed if they're already compressed in their file. This allows me to keep some textures lossless if the compression garbles them up (often the case with normal maps).


-Bean
_________________
Kevin Reems | Nuclear Playground | Solid Driver
View user's profile Send private message Visit poster's website
BadMrBox
Developer

Joined: 12 Jun 2006
Posts: 1203
Location: Beyond return
PostPosted: Tue Aug 27, 2013 7:12 am    Post subject: Reply with quote

Pretty damn good work :)
_________________
My Blog | I take steroids for my bad knee. Now I can kick a smart car across the Walmart parking lot![/size]
View user's profile Send private message Visit poster's website MSN Messenger
Bean
Admin

Joined: 20 Aug 2005
Posts: 3772

PostPosted: Wed Sep 04, 2013 2:19 pm    Post subject: Reply with quote

One of the last things I had to get working with the renderer was Render to Texture. I had put it off for quite awhile because I remembered it being a bitch when I first put it in using DirectX9.
I was pleasantly surprised that DirectX10 simplifies this and it was actually quite painless. The function for my scope for example is down to 3 lines and a basic loop:

Set Render Target
Set Camera
Clear Render Target
Draw Shit

I like it. I also had a transparency bug in my shader's blend state which was made obvious while testing the scope. I was able to fix it and as a result this also solved the problems I was having with saving PNG files. So I added a pref to select the file type for screenshots. Jpeg will remain the default.


-Bean
_________________
Kevin Reems | Nuclear Playground | Solid Driver
View user's profile Send private message Visit poster's website
Bean
Admin

Joined: 20 Aug 2005
Posts: 3772

PostPosted: Sat Sep 07, 2013 9:00 pm    Post subject: Reply with quote

Here's an experiment I've been wanting to try for about 6 months. Instead of rendering the view of the world directly to the backbuffer, render it onto multiple textures. The view is divided up into foreground, midground(s), background. Each of these on it's own texture. Then each of these are tossed onto the backbuffer like a stack of layers.
The idea being that each of these textures is smaller. So objects on distant layers would be less detailed but you'd gain speed.

Here's what it looks like. Mind you I would have to clean up the outlines shown here but for now they actually help illustrate.



There's only one problem with this..
It's balls slow! Far slower than just rendering everything in full detail. It probably would have been a good idea some years ago when GPU's struggled. In fact I actually got the idea from the Wii game Driver (although I think they used pre-rendered cube maps). Apparently current hardware (and my video card is like 5 years old!) has an easier time just pumping out graphics than switching through multiple render targets, shaders etc in order to do multiple passes on the same scene. Even when culling objects not included in each layer.


BUT!!
DirectX10 and later actually support multiple render targets at the same time! Up to 8 I believe. It may be possible to render each layer in parallel. Wouldn't that be super duper!? ...Considering Diversion's getting very reasonable framerates at the moment I think I'll go down that road another time.


-Bean
_________________
Kevin Reems | Nuclear Playground | Solid Driver
View user's profile Send private message Visit poster's website
Sirocco
Moderator

Joined: 19 Aug 2005
Posts: 9441
Location: Not Finland
PostPosted: Sun Sep 08, 2013 7:43 am    Post subject: Reply with quote

That's good for post-processing of frames, but as you've observed isn't really suited for what you're describing. I think you can accomplish something similar by passing the z-buffer into a shader to blur distant objects. Or, I might just be thinking of things that rhyme with zucchini and Biz Markie.

Oh god, my brain.
_________________
NoOP / Reyn Time -- The $ is screwing everyone these days. (0xDB)
View user's profile Send private message Visit poster's website
Bean
Admin

Joined: 20 Aug 2005
Posts: 3772

PostPosted: Sun Jul 06, 2014 11:46 pm    Post subject: Reply with quote

My job's been kicking my ass lately (12 hour shifts suck!), hence my lack of activity the past few weeks. I'm back in action once again.

As long as I've had Mutiny running on DirectX10 it wasn't until today that I updated the display preferences. DirectX9 handed the changes of screen modes very crudely compared to later versions. No longer must you re-load all of your textures and such just to change the resolution for example. This is boring shit but I've spent a day working on it. Now you can switch in and out of fullscreen or resize the window pretty much instantly.

I have a few other things to update, like anti-aliasing before I dive back into the game of Diversion.



-Bean
_________________
Kevin Reems | Nuclear Playground | Solid Driver
View user's profile Send private message Visit poster's website
Bean
Admin

Joined: 20 Aug 2005
Posts: 3772

PostPosted: Tue Jul 15, 2014 10:35 pm    Post subject: Reply with quote

For the longest time I would trumpet, "Options are always a good thing!". And for the most part I still believe that is true. But throwing a shitload of options at a player for no good reason can actually be a bad thing. I realized while updating the screen mode switching and such that my UI needed to be simplified. Here is a before and after..




As you can see I've axed most of the display options. Most of those give little performance gain and can make the game look like shit. More importantly, most players won't know what half of that shit even means. Most of the options removed from the menu are still accessible via the settings file if any geeks care to mess with it.
Others, like Anti-Flicker have been removed entirely as they are no longer needed. Anti-Flicker attempted to resolved a depth buffer issue. I'm now using a 32-bit buffer and tweaking the camera's projection matrix depending on what's happening in the game. Problem solved :)


-Bean
_________________
Kevin Reems | Nuclear Playground | Solid Driver
View user's profile Send private message Visit poster's website
Gil
Developer

Joined: 14 Nov 2005
Posts: 2341
Location: Belgium
PostPosted: Wed Jul 16, 2014 7:17 am    Post subject: Reply with quote

Bean wrote:
Most of the options removed from the menu are still accessible via the settings file if any geeks care to mess with it.
Yeah, that's the best option hands down
_________________
PoV: I had to wear pants today. Fo shame!
View user's profile Send private message Visit poster's website
Bean
Admin

Joined: 20 Aug 2005
Posts: 3772

PostPosted: Thu Jul 17, 2014 8:17 pm    Post subject: Reply with quote

Glad someone agrees :)

I just finished up the display type crap. Mutiny plays nice with Windows now when focus is taken away, alt+tab, alt+enter, switching to another app while in fullscreen and all that kind of jazz. It's much more fluid than before since the switch is nearly instant now.

I also changed how the game handles showing/hiding the mouse cursor which ties into the above. So if you're playing in a window you can still use the mouse like a fullscreen first person shooter but if you need to fuck with another window you can smack Esc to open the menu and get your cursor back. Do your thing, then jump back into the game again.

-Bean
_________________
Kevin Reems | Nuclear Playground | Solid Driver
View user's profile Send private message Visit poster's website
Reply to topic GDR Forum Index -> Game Developer's Refuge -> Development Log - Mutiny Engine Page Previous  1, 2, 3 ... 13, 14, 15
Game Developer's Refuge
is proudly hosted by,

HostGator

All trademarks and copyrights on this page are owned by their respective owners. All comments owned by their respective posters.
phpBB code © 2001, 2005 phpBB Group. Other message board code © Kevin Reems.