So I’ve been recovering from the UI, fixing stuff like scissor rectangles and streamlining the setting of viewports and render targets. Since we need the render code to be as fast as humanly possible, I’ve been fiddling a bit trying to eliminate unnecessary state switches. Anyways…
We’ve had a small problem with using the physics for picking in the level editor. So I thought, hey! Why not adding per-pixel picking by rendering IDs for each entity to a buffer. This gives us a very nice projected representation of our scene, so we could just pick the pixel at the mouse position and voila, we have our entity! The only thing is that the render system isn’t and shouldn’t be dependent on the application system. So we need to be able to pick a game entity by clicking in screen-space, but we only actually have access to graphics stuff when rendering. What I did was to add a picking integer to the model entity, which is simply a generic identifier which we will use for picking. Instead of directly associating the game entity with the model entity, we instead use a generic identifier.
Note that we may want to use screen-space picking for other things than just the level editor, such as RTS selection, shooting in FPS or whatever. The only downside is that we must render everything again. We could just add this to our deferred rendering path, but we may also want to disable this feature to improve performance for games which doesn’t need pixel-perfect picking.
You may want to know what the title is all about. Well, I’ve also made it so that the content browser and level editor can communicate with each other. This means we can be in the content browser and edit stuff, save it and it will be immediately updated in the level editor. This is beautiful for many purposes, because an artist can sit in the content browser, fiddle around with their assets, and see how it would look in the level editor on the fly.
I’m trying to think of some image to put here just to show you how this works, but this week is highly functional, but not so much graphics related.
Ok, well, maybe that’s not entirely true…
While also implementing per-pixel picking, I’ve also done some work regarding the limitation of window size. I’ve made it so that we can re-size the entire Nebula context, and make every render target and render plugin get updated with the new screen size. This means we can have a variable-size window and render space, without losing quality or getting weird-looking aliasing artifacts. It’s also important for the render modules to get information about screen re-sizing, the UI for example needs the new dimension of the screen to properly scale and map mouse positions. The only downside to the re-sizing is that it of course costs a lot because every single render target needs to be destroyed and recreated.
An alternative to re-sizing the render targets could be to always render to a big render target, and then simply change the camera matrix to just view a portion of the entire frame. This might be an alternative, but since we couldn’t change the resolution in real-time before, I figured we might want this feature anyways.
I also realized I made a slight boo-boo with the bloom post effect, so that has been resolved and looks much better (like Vaseline on glass).
If that wasn’t enough, I also took the time to restore the old FX system in Nebula. It worked, sorta, the only problem it had was that it didn’t really respect the render-application thread border in any way. So I thought I could fix it so that it wouldn’t randomly crash. So now we can spawn fire’n’forget effects like camera shakes, camera animation tracks and time-limited graphics entities. Sadly, I’m too lazy to show you any pictures…