next »

[Crimsontide]

So you're basically cone tracing?  Would it not be straight forward to solve the equation for triangles?  That would cover all your standard use cases would it not?

[powly]

What do you do about combining several points that happen to land in the same pixel? There the correct solution becomes pretty difficult to figure out pretty quickly.

Depending on your definition on "cone tracing" it might be just this or something quite else. And similar solutions for triangles have existed for quite a long time, it's just that they are required to be depth-sorted for it to work and even then it's not exact if you don't find out the exact areas by clipping the geometry inside each pixel or something.

[Crimsontide]

I had similar thoughts, I was hoping he'd clarify.

My thinking is that this was a cool thing to do 'just because'/'for shits'n'giggles'.  Which in and of itself is a worthwhile endeavor.  That said, I don't see how this would be remotely useful in practice.  Multi/super sampling would be orders of magnitude more perforaent I imagine, with similar quality.

[Schrompf]

First and foremost: it's an experiment. I wanted to try this, and it turned out to work nicely with rectangles.

The issue with triangles is: points in a cloud are not expected to cover space gap-free. It's more of a statistical approach, and at that it's far superior to multisampling of any kind - it requires way less computations and memory writes than multiple samples and provides much more precision.

Now triangles are expected to form a contiguous surface. So you can't get away with handling a single triangle at once. When you're done calculating the coverage for one triangle, the information about which parts of the area were covered is lost. And a second triangle covering the same fragment would not know how much of the fragment area it erases, and how much it supplements. At the moment I have no idea how to solve this, every idea I have is some sort of sampling grid, and the whole idea was to get rid of that.

My voxel renderer could make use of this, though. For that rendering point clouds would still suffice, but a different point shape would be highly appreciated... I don't know. I'll let it sink, and pick up the topic some other day.

[edit] Oh, and yes: the point cloud is required to be depth sorted. I built sort of a parallel bucket sort which works nicely, but I really need to measure exactly and put it up against plain std::sort()

[Crimsontide]

First and foremost: it's an experiment. I wanted to try this

No judgements here, there's no better way to learn  I mean I spent most of this morning reading FPGA datasheets... just because.  So I'd be the last person to mock/denigrate someone for doing interesting/creative/different stuff.

Now triangles are expected to form a contiguous surface. So you can't get away with handling a single triangle at once. When you're done calculating the coverage for one triangle, the information about which parts of the area were covered is lost. And a second triangle covering the same fragment would not know how much of the fragment area it erases, and how much it supplements. At the moment I have no idea how to solve this, every idea I have is some sort of sampling grid, and the whole idea was to get rid of that.

Well if you're computing the color of a single pixel, you just need to know the amount of coverage, and the order in which it occurs.  As long as the triangle don't intersect, the solution seems pretty straightforward to me.  Intersecting triangles could be converted into non-intersecting ones by a pre-pass over the triangle data.

Reyes does something quite similar in that the surfaces are subdivided into micro triangles, which are then rendered.

[Schrompf]

Thanks, I'm pretty sure I'm not the first to come up with this, so I'll keep an eye out for what others day. Just one last thing on the topic of triangles: I meant adjacent triangles. Connected triangles. The common edge that two triangles share will get miscalculated because of the phenomenom I outlined above. I have yet to come up with an idea how to solve this.

[powly]

That was also my question; how do you deal with it currently? Some multiplicative approximation?

It’s an interesting experiment, always feels good to see someone try something out of the box!

[Schrompf]

I don't deal with it at all. That's the nice thing about a point cloud - they don't line up. I simply sort them back to front and then blend each point's color separately into the pixel according to their coverage times alpha.

[powly]

I’d say that’s already a way of dealing with it you still get potentially arbitrarily wrong results; for example if you have a red background and two green points cover it completely (both by a half, one on the right and one on the left side) the result is not green but a yellowish mixture.

But yes, it’s not overly visually distracting for a sparse-ish point cloud.

[pelle]

Last night finally completed an addon for Godot I have been working on for a few nights spread out over several months.  It adds importers for most Autodesk Animator file formats. On github soon.

Imports animations (FLI) to spritesheet textures (can config rectangle to cut out for smaller sprites), images (CEL and PIC), polygons (PLY), palettes (COL, as textures, whatever you could use those for), and masks (MSK, as Bitmap resources that I have no idea what they are for).

Todo: Figure out a good Godot representation for macro recordings (REC) files (lists of coordinates with mouse button and keyboard states and optional timing information).

Just looking at those old simple binary file formats makes me happy.

EDIT: Tbh only the FLI, CEL, and PIC files are likely to be of much use, but the other types were easy enough to parse that why not.

EDIT2: https://github.com/lifelike/godot-animator-import

[oahda]

I'd been so worried about integrating Bullet for physics into my engine because for some reason I'd gotten the impression that it was one of those nasty libraries that are almost impossible to build without using their supplied make/cmake/premake setup or scripts and then linking against them (which is fine for some projects, but I wanted to compile it as part of my own codebase using my own such setup that works on 6+ different platforms), but once I actually got around to it today, it only took me about an hour to add the library and test it with my existing 3D scene!

I literally just had to copy the Bullet code from the src/ folder over to my own project and add the directory to the header search paths, and that was it. <3



(looks weird because the cat has a mismatched sphere collider and is rolling around on an invisible floor, but it's working!)

[Crimsontide]

Vulkan library is up and running, 3D textures are working, tomorrow I start working on voxel raytracing.  Kinda excited

[oahda]

Cool! How are you liking Vulkan?

[Crimsontide]

Cool! How are you liking Vulkan?

90% is great... 10% is WTF!??  Its way better than DX 8-11, and OpenGL, never tried DX12.

Big problem is there is almost zero info on it beyond the spec.  The 'vulkan' forums are pretty much filled with assholes just trolling anyone who asks a question.  The few tutorials/slides/youtube videos are bare-bones and pretty much useless when it comes to issues/bugs.

I dunno, its funny, some parts are so well done, and others... so not.

[ProgramGamer]

Sounds like there's an untapped market for making Vulkan tutorials

[gimymblert]

3D textures are working, tomorrow I start working on voxel raytracing.  Kinda excited

Funny I have been doing that lately
https://forum.unity.com/threads/segi-fully-dynamic-global-illumination.410310/page-44#post-3828610

[ThemsAllTook]

For the last couple of years, I'd been feeling super burned out on game development, and got basically nothing done. I think it's finally wearing off. I recently started allocating half an hour of time every morning to write just a little bit of code and get things moving.

Results have been super good so far. I'm working on two different game prototypes and feeling really excited about both of them. When it's happening every single day, half hour work units add up really quickly, especially compared to the "whenever I feel like it while burned out, which is almost never" schedule I'd been on before. In the last week, I've set up a whole new 2D rendering system, and solved a bunch of long-standing problems in my development framework.

Establishing this kind of structure where I know when I'm going to work each day and don't have to think about it every time to figure it out is a huge help. When I have extra time and feel like doing more, I do more, but just having that basic heartbeat of half an hour every morning has gotten everything flowing so much better.

[oahda]

Yay! Glad to hear it! Are the prototypes something you can/wanna tell us about? c:

[ThemsAllTook]

Hmm. I usually try not to talk about these things too much until I'm sure I'll be able to show something, but writing down some thoughts here might actually help me organize them...

I've recently started a project where I'm playing the entire Final Fantasy series from beginning to end, streaming it on YouTube, and analyzing the story and mechanics as I go. A few interesting things stood out to me about the battle system, at least in the first game. The number of interesting moment-to-moment choices I can make is actually very limited. Unlike a lot of more modern games I've played lately, it's not really possible to overcome a strong enemy with skill alone. My party is either leveled up and geared well enough to handle a given encounter, or it isn't. How could this system be remixed to work differently?

The idea that came to me was that instead of trying to make the moment-to-moment decisions more interesting on their own, what if everything was decided up front? Each encounter would turn into a puzzle box where you'd choose which equipment and spells to bring, and program your party members to behave a certain way. A really simple example would be to set down a pattern where they'd spend three turns attacking, one turn healing, then repeat. The challenge is to come up with a setup that wins the encounter with no additional input from the player. The enemies would work in the same way - maybe you can inspect their equipment and behavior up front, or maybe it's more interesting if you have to observe how the battle plays out and tweak your setup after you see what they do. I can play around with showing or hiding different bits of information and find out which way makes for a more interesting game.

The second prototype is another reinterpretation of an RPG combat system. Imagine a real-time first-person dungeon crawler where your combat interface is a UNIX command line. To cast a fireball spell, you invoke the 'fireball' program and have to give it the appropriate arguments for target, power, etc. You can see your opponent typing their own invocations, and if you're quick enough, alter what you were typing to counter it. There could be things you find in the world to unlock macros, abbreviations, reprogramming for your spell commands, and stuff like that. This might be more interesting as a competitive multiplayer experience? I haven't spent as much time with this one yet as the other one, but it's definitely something I want to try out and see if there's a viable game somewhere in there.

Even if neither one of these works out, they've at least gotten my creativity flowing, and given me specific goals that I can use to direct improvements to my game framework. The hope is that after using it for a few more prototypes, the framework will be stable and complete enough that I won't have to get mired forever in back-end work when I just want to jam out some gameplay. I've been working toward this goal for several years, and it feels like I'm getting pretty close to it now.

(For those of you who reply to any hint of someone writing their own framework with "just use Unity", I've already heard this a million times, and I've tried it and it doesn't agree with me. The only way to get the level of control I need is to do it myself.)

[ProgramGamer]

The "setup the battle and watch it unfold" thing has actually been done in some way by Megaman Battlechip Challenge on the GBA. It's not a good implementation at all because there's way too much randomness involved and you have no control over the battle once it starts, but it might be worth looking into it.

And, now that I think about it, what you're describing kinda sounds like a zachtronics game lol