@reduz@mastodon.gamedev.place
@reduz@mastodon.gamedev.place avatar

reduz

@reduz@mastodon.gamedev.place

Co-created Godot Engine with Ariel Manzur, and later with an awesome community. Currently tech lead (or more like advisor).

I specialize in all things game engines (rendering, physics, audio, scripting, networking, file formats, etc).

This profile is from a federated server and may be incomplete. Browse more on the original instance.

reduz, to random
@reduz@mastodon.gamedev.place avatar

Heyo folks, I will be trying to upload videos weekly to Youtube explaining the Godot codebase in detail. Today is the first one, so make sure to subscribe!
https://www.youtube.com/watch?v=vTlEM2tJavo

reduz, to random
@reduz@mastodon.gamedev.place avatar

Back in the early 90s when I started programming, my first PC (386dx) came with a copy of an IBM Model M keyboard that had mechanical switches. I loved typing on it, so in the late 90s when all keyboards became membrane keyboards I was very sad.

Luckily, by that time, I found a sale of a old Model M keyboards in Buenos Aires and purchased 3 or 4. The quality was not great (switches break after some time) but this allowed me to keep typing mechanical until it miraculously became trendy again.

reduz,
@reduz@mastodon.gamedev.place avatar

@tuto Clicky all the way, that's the only way they mechanical keyboards existed back in the 80s and 90s. The feel / no sound is a new thing.

reduz,
@reduz@mastodon.gamedev.place avatar

@pythno As a Desktop Linux user, I just don't use it.

reduz,
@reduz@mastodon.gamedev.place avatar

@badlydrawn Very heavy, same as modern ones. A lot of people have them on a pedestal and, while the feel was great, the quality was junk. I used them for around 16-17 years and every 5/6 years they would go bad (some switch breaking) and I had to switch to the next one. I am so happy these things became trendy again.

reduz,
@reduz@mastodon.gamedev.place avatar

@badlydrawn You can see in this video how the buckling springs worked, it was entirely different to modern switches and very prone to breaking:

https://www.youtube.com/watch?v=VsIr8dl_7Kk

reduz, to random
@reduz@mastodon.gamedev.place avatar

As requested, added to this renderer design an OIT transparency implementation.

https://mastodon.gamedev.place/@reduz/111278930770349586

reduz, to random
@reduz@mastodon.gamedev.place avatar

Some ideas for a GPU driven renderer in Godot. This is definitely 2024+ material, but does not hurt to start planning:

https://gist.github.com/reduz/c5769d0e705d8ab7ac187d63be0099b5

reduz,
@reduz@mastodon.gamedev.place avatar

@OscarRobin Yeah the other renderers we have are better suited for low end.

reduz, to random
@reduz@mastodon.gamedev.place avatar

I know this is unpopular opinion, but to me the idea of standardized tonemappers in games makes very little sense. Unless you are going for ultra-realism and want to achieve the same look as in film with the same physical lighting parameters (far most people don't) and physically captured textures (not art-generated), there is little reason to have this as a "standard" rather than just adjust to whatever looks good for your game.

reduz,
@reduz@mastodon.gamedev.place avatar

@newin My understanding is that tone mappers originally come from movie and picture industries, where a consensus is built on how to convert something that is a capture of physical light will be best represented on printed media or film with a lower dynamic range or physical characteristics than what the eye can perceive. As such, it for the most part applies to mapping physical light interaction with objects to a photo/print/display device...

reduz,
@reduz@mastodon.gamedev.place avatar

@newin But for games, in general, you are dealing with artistically created objects portrayed in an artistic way, not "real life", hence while sure, tonemappers can play a role depending on the level of realism you want to work with, ultimately they don't serve such a useful propose unless you are going with hyperrealistic asset captures, lighting and rendering.

reduz,
@reduz@mastodon.gamedev.place avatar

@BartWronski Oh yeah I don't disagree with this take, but as I said this makes sense only if you are going for realism in the look (say working with substance). A large amount of games does not, this is specially evident if you leave the AAA space.

reduz,
@reduz@mastodon.gamedev.place avatar

@BartWronski Sure, but if you are not going for realistic lighting (typically with constant ambient lights, tweaked GI or diffuse wrap for artistic look, etc. It will still look quite different than in Substance. Even the color grading generally makes the model shading look really different.

reduz,
@reduz@mastodon.gamedev.place avatar

@BartWronski I fully agree, but this further makes my point I think. Imagine the art creation (Maya, Substance, etc) did not apply any tone mapping curve, just Gamma. Then you don't in your game engine.

Artists would not complain, assets would look the same everywhere. Then why do we have the custom "standard" tone-mapping curves? Because renderers try to emulate film.

reduz, to random
@reduz@mastodon.gamedev.place avatar

As promised a document explaining the process of transitioning from Larvita 3 (the previous engine we made before Godot) to what Godot is today:

https://gist.github.com/reduz/9b9d1278848237fd9a9a8b6cc77c8270

reduz, (edited ) to random
@reduz@mastodon.gamedev.place avatar

What kind of developer are you? Say you are working on an enemy type.

Some devs will create the base enemy and hardcode all logic of all enemy variants for this type of enemy, then inherit that enemy and create variants by modifying attributes. They justify this is less work.

Other devs will go the full composable route, where all potential behaviors are components, then the variants for this enemy are compositions of the different attributes and components. They justify order & flexibility.

reduz,
@reduz@mastodon.gamedev.place avatar

@newin Yeah, life has taught me the same. It's like the Jedi IQ bell.

reduz, to random
@reduz@mastodon.gamedev.place avatar

Given there is some interest about this, I did the exercise of writing how I believe Godot should support something like the Apple Vision Pro.
Seems it should be fairly simple if anyone is interested:
https://gist.github.com/reduz/f5ffd70f1082b762e0492112a449f7f2

reduz,
@reduz@mastodon.gamedev.place avatar

@conjurenation Godot is not a company where people working on it are told to spend their time on what the project needs. It is a FOSS project where people contribute to work on what they like and want. If someone wants to support this or any other hardware and contribute an implementation, it will obviously be welcome.

aras, to random
@aras@mastodon.gamedev.place avatar

Quick garden tools capture with Gaussian Splats, with whole data in under 8 megabytes: https://youtu.be/iccfV0YlWVI

GS data made with poly.cam, then into https://github.com/aras-p/UnityGaussianSplatting and using "Very Low" quality preset the whole final data is 7.6MB. And I think it could be compressed further! Just someone has to spend a bit more time.

Pretty cool how well the metal shading including brushed/anisotropy is represented, I think.

reduz,
@reduz@mastodon.gamedev.place avatar

@aras This is quite awesome. One thing I am not understanding much is why nobody in the AI field is doing anything to actually turn this into geometry with PBR materials. You have the full info, including the BRDF.

The way I see it is that you can generate an infinity of training sets from existing PBR models, then train the reverse path.

This way you can turn any object you film with you camera into a 3D PBR model to use in a game..

reduz,
@reduz@mastodon.gamedev.place avatar

@aras Seems like a huge waste of business opportunity to me. Guess everyone in the AI field is too busy with language models.

reduz,
@reduz@mastodon.gamedev.place avatar

@zeux @aras I am not sure you need Gaussian splatting as intermediary. in fact NERF may even be better in this case (there is code to convert it to geometry).

The thing is that, since you have a ton of PBR models available as GLTF2 with CC licenses, a training set where you go model -> photogrammetry -> reconstruction should not feasible.

I talked to a lot of companies working on photogrammetry and people doing these kind of things and nobody seems to be interested in this research.

reduz,
@reduz@mastodon.gamedev.place avatar

@BartWronski @zeux @aras I understand this, but IMO, it does not have to be perfect (as in, can focus into non-transparency) to be useful. I did not look at every paper out there, but most of what I've seen only focus on photogrammetry.

Haven't seen anyone focusing on generating training sets from actual 3D scenes/models done by non-realtime renderers, which can be used for BRDF ground truth while training.

reduz,
@reduz@mastodon.gamedev.place avatar

@lritter @aras Oh yeah I guess with a special rig you don't even need to use AI. I was referring to generate proper proper materials from objects you can capture by moving your camera around them in the world.

You would definitely need AI to properly guess albedo, orm and do shadow removal.

  • All
  • Subscribed
  • Moderated
  • Favorites
  • •
  • JUstTest
  • kavyap
  • DreamBathrooms
  • khanakhh
  • magazineikmin
  • mdbf
  • tacticalgear
  • osvaldo12
  • Youngstown
  • rosin
  • slotface
  • ethstaker
  • everett
  • thenastyranch
  • megavids
  • InstantRegret
  • Durango
  • normalnudes
  • Leos
  • tester
  • ngwrru68w68
  • cisconetworking
  • cubers
  • GTA5RPClips
  • anitta
  • provamag3
  • modclub
  • lostlight
  • All magazines
    •