Work Blog - JeffR

328 posts Page 30 of 33
Duion
Posts: 1132
Joined: Sun Feb 08, 2015 1:51 am
 
by Duion » Sun Jul 15, 2018 9:42 pm
There is lot of Unity games made using plugins and game templates by people that don't know anything about coding, and hundred mobile games also made without any coding.
It looks like you are not very aware of Unity vast possibilities
A game using "plugins" and "game templates" that is made without any coding is called an "asset flip".
Yes, if you quickly want to make lots of mobile "games" without any efford and scam money out of people Unity seems to be your best choice.
Razer
Posts: 38
Joined: Tue Jan 10, 2017 11:29 am
by Razer » Sun Jul 15, 2018 10:36 pm
There is lot of Unity games made using plugins and game templates by people that don't know anything about coding, and hundred mobile games also made without any coding.
It looks like you are not very aware of Unity vast possibilities
A game using "plugins" and "game templates" that is made without any coding is called an "asset flip".
Yes, if you quickly want to make lots of mobile "games" without any efford and scam money out of people Unity seems to be your best choice.
Nope.
You mean fps creator or rpgmaker are asset flippers ?

When you change almost nothing and sell the game template as a game, it's an asset flip.
When there is lot of work to change all art or cutomize scripts making the game template almost no more recognizable, it's not an asset flip.

I have some insight within some games made by indies and i tried their sort of pre alpha demos, after they told me what plugins or templates they used, i was very surprised how far they could customize or push some plugins and game templates to get such great games.
Without those templates their game would not have been possible, game templates are a very huge boost to start making your own game , every major 3D engine has default game templates for free and directly included as starting point to make your game.
Why loosing time re inventing the wheel ?
JeffR
Steering Committee
Steering Committee
Posts: 878
Joined: Tue Feb 03, 2015 9:49 pm
 
by JeffR » Mon Jul 16, 2018 4:19 am
@
User avatar
Razer

At this point, I'm not even sure what your point is.
Azaezel
Posts: 413
Joined: Tue Feb 03, 2015 9:50 pm
 
by Azaezel » Mon Jul 16, 2018 5:38 am
Pretty sure he's referring to stuff like the old racing game vs fps type deal we'd discussed as wanting to do as part of the template refactor. Is that something you would want to assist with speeding along, @
User avatar
Razer
, or another feature request?
JeffR
Steering Committee
Steering Committee
Posts: 878
Joined: Tue Feb 03, 2015 9:49 pm
 
by JeffR » Mon Jul 16, 2018 5:47 am
Oh, dang it people did some replies when i went to post. heh.

Ok, so this discussion originally started with talk about engine-side contributions. If you were trying to discuss having a solid launch-off point so people focusing on doing a game rather than engine work can get on with that, then sure, I complete agree.

I've made mention in here that what I want is to have a series of Rapid Prototype Kits - basically micro demos of assets to fufill a basic gameplay mechanic or whatnot that you could take a few, drop them in and use it as a starting point to build the actual unique elements of your game upon. It's definitely a good thing to have plenty of those workable bits for people to jumpstart on, or skip having to re-implement a common gameplay mechanism over and over every time like say reloading a gun.
Duion
Posts: 1132
Joined: Sun Feb 08, 2015 1:51 am
 
by Duion » Mon Jul 16, 2018 10:19 am
It is simply a marketing lie to claim people can make games without any skills.

Sure you can make it so easy anyone can produce something, but that does not improve the situation at all, from my experience in level design, as the level editors got easier, the quality of levels designed dropped rapidly, we have the same with games.

And to my opinion game engines and templates are the same, for example with Torque the template first helped me greatly, but after some time it hindered me, since I did not build the foundation and therefore did not know how it worked, so I had to learn how to make the engine work without template later anyway.

Same with "sample" art assets, the Torque demos are of such high quality since they are made by professionals, that almost no hobby developer will ever reach that quality himself.

@
User avatar
JeffR

So I think the idea of having Rapid Prototype kits is a good thing, but don't start making super complex templates or too good "sample" assets, otherwise most people will never achieve anything better on their own as I described with the Torque demos.
However I still do not think having those super better templates will help anything in making Torque3D more popular, almost the only thing that increases popularity is marketing, you have to advertise first, then deliver something later, on the other hand when you create a product where there is no market nothing will happen.
JeffR
Steering Committee
Steering Committee
Posts: 878
Joined: Tue Feb 03, 2015 9:49 pm
 
by JeffR » Mon Jul 16, 2018 3:50 pm
@
User avatar
Duion

Oh yeah, for sure. The RPKs would absolutely not be full demos with fancy polish or anything.

I did figure on some larger-scale ones that act as a baseline for a general gameplay style(similar to how the full template acts like a basic FPS deathmatch shooter) but it obviously wouldn't be intended as a stand-in for a full project.

The RPKs would be fully design and intended to act as a foundation for people to jump past the really common things so they can work on THEIR actual gameplay. Never figured them to be fully polished fancy demos or anything like that.
damik
Posts: 54
Joined: Thu Jun 23, 2016 12:02 pm
by damik » Fri Aug 10, 2018 12:29 pm
Last edited by damik on Mon Aug 20, 2018 12:30 pm, edited 1 time in total.
JeffR
Steering Committee
Steering Committee
Posts: 878
Joined: Tue Feb 03, 2015 9:49 pm
 
by JeffR » Mon Aug 13, 2018 4:37 pm
Ah, yeah, I've seen some similar techniques before. That one does look to produce some pretty nice results. Main thing for the horizon/hemisphere sampling techniques is they can be a little expensive but if works in PoE it's probably pretty efficient.

Good find :D
JeffR
Steering Committee
Steering Committee
Posts: 878
Joined: Tue Feb 03, 2015 9:49 pm
 
by JeffR » Tue Sep 25, 2018 7:24 am
Hey everyone! Time for a work blog!

I meant to do this days ago, but kept getting invested in dev work and before I knew it, it was well into the early hours. And you know I like to type, so I kept having to put it off.

So, what's been going on? Quite a bit of stuff, that's what!

Roadmap Progress
Roadmap progress is a bit behind, but still chugging along. The main culprit is Screen Space Reflections being a butt-wrench. The main initial PBR PR is pretty well good to go on the D3D side, and there's a few bugs to crack on the GL side, but the bulk of that work is actually good to go for testing and integration. SSR, however, has proven to be a "this is almost right, but that last bit is completely, utterly wrong" sort of deal.

The issue is that to calculate SSR properly, we have to regularly juggle between Screen space and view space. And to get those, we need a bit of worldspace or camera space info. Jumping between relative spaces like that involves multiplying whatever vector or position you're trying to work with with a matrix in the right orientation, which basically changes the relative values to be in whatever space you want.

Think of it like how if you hold an object out in front of you, in your local space, it's X distance away(arms length) but you'd have to change what 'space' you're thinking in to consider where it's position relative to the entire room is. To do that you'd have a 'room space' matrix you multiply the object's position by. To move it back, you'd have to multiply your origin position.

So given that these matrices are pretty much the only way we can convert values, if they're off, at all, then the space conversion fails and all your data is buggered, which has been our main hangup. We have solid examples to work from, but some of the input values that post effects by default have aren't quite correct if we want to swap spaces. Normally this doesn't matter, because Post Effects don't really swap between. It's either a screen space effect, or view space, or world space, and doesn't ever hop between. Now that we are, some values that were thought to be right are not, and that's been slowing the whole thing down.

Still, we've been chopping our way through and getting everything lined up data wise to be correct, so it's only a matter of time before the SSR implement is sorted and in.

Beyond that, there's the module-ification of the core directory in the Base Game template, which is PR'd and just needs to be run through the tester before rolling in.

I also begin work on the Assimp integration. Bulk of the loader code is there, but the actual assimp-to-internal formatting still needs work, as you can see below:
Image

Poor guy has some issues, yet. Good news is, I'll be working on this when I'm not working on SSR, so it should be ready in the near future, which should be quite a nice boon to the art pipeline.

Lightmapping
So, T3D's technically had lightmapping since forever, but it was a really weird half-baked implementation that required duplication of materials and other performance-obliterating things.

I thought that was suuuuuper dumb, and wanted lightmapped interiors for my personal project, so I took a look into real, in-engine baked lightmaps again.

The notions are simple. You shoot rays around, when they hit a triangle, you map the UV coordinate of the hit, and write a bit of lighting info into a texture based on the second UV channel. Save that file out, then when you go to render, load that and dynamically override the tonemap inputs for shadergen so we can bypass the awful hardcoded method mentioned above.

Good news is, the latter part was actually minimal effort involved because of the earlier-mentioned Custom Shader Feature stuff. Since that not only lets you write entire shadergen features in script, but also lets you pass along custom shader binding data, it was pretty straightforward to add a field to TSStatics that take an image, then force-enable the tonemap material feature on the shape's materials.

From there, during the render setup, we bind that to a bit of custom shader data with the tonemap name(the name of the field in our shader we'll pass said data to) like so:

Image

This data stays attached to the render instance and passes all the way along, is paired with the specific material instance(so even if you use the same object with the same material, each object would have it's own lightmap texture passed along. This is important because it means absolutely minimal additional render overhead for lightmaps without needing to tank render performance by state changing to a totally different shader or material)

The end result is it binding that per-instance texture to the tonemap shader input, which then does the normal shader logic to apply the lightmap texture to the rendering on a per-instance basis. So that actually was relatively smooth(and you can expect this stuff to go into the engine in the near-ish future after some cleanup)

The trickier part is actually the first bit, with plotting the actual rays themselves. As-is, T3D only generates tex coordinates for the first UV channel, not the second. I need to spend more time looking through HOW it generates that to know how to enable the switch, but this is important because the lightmap UV channel is very often VERY different to the one that is used to do the main rendered textures. Especially if you utilize tiled textures.

Once that's working, we can basically blit our ray hits into the texture. There's been some weirdness during my testing about live-updating the texture during our bake, but that could be due to the issues above with not properly having coordinates to use and it's throwing the whole blit-and-go part off.

That said, initial basic attempt and testing ray intersection is going decently:



That's not doing the blitting(which is, as said, broken) but it does generate a debug dot at each hit. Even though it very clearly biases on the equator instead of an even circle at the moment, you can already see how you get a 'shadow' in the constellation cast behind the pillars and the like. Once that and blitting works, we can get secondary, teriary and so on rays to get the smooth irradiance lighting that makes lightmaps so sexy.

Once all that's in, the basics of lightmapping is there and it'll be ready to use for the most part. Looking forward to the future, however, I want to implement Volumetric Lightmapping.
It's basically exactly like lightmapping, except during our ray casting, we actually do a ray march through a 3d texture and sample in our light info at each voxel. We note the direction, color, intensity, etc of said ray, and at each voxel then compute a Spherical Harmonic value.

This is written into the 3d Texture and used during rendering so at each point in space(not just the mesh surfaces) you can get specific, directional light information from the lightmap bake - volumetric lightmapping. This means that when your player walks behind the pillar which blocks the direct lighting as per the video, they'll still get very good directional lighting information from the indirect bounces. Effectively a dirt-cheap precomputed global illumination.

Other advantages are that this can be sampled in Volumetric Fog, to create VERY high-fidelity volumetric lighting info in the fog itself, allowing for view-independent godrays in the fog, as well as a much, much more accurate sense of depth.

I'm sure I've forgotten a few bits, and if I can remember them, I'll update here. But that's the bulk of what's been shaking down at the moment. Feel free to drop in the Discord if you haven't already because we're cooooonstantly babbling on about this stuff and you can see us work through a lot of this as we go - which I'm told is fascinating ;)

Until next update, later guys!
-JeffR
328 posts Page 30 of 33

Who is online

Users browsing this forum: No registered users and 3 guests