mirror of
https://gitlab.com/drummyfish/anarch.git
synced 2024-12-22 07:18:49 -05:00
74 lines
4.1 KiB
Plaintext
74 lines
4.1 KiB
Plaintext
> well I use discord typically. Gek#9082
|
|
|
|
I never use discord. Things I use or can use:
|
|
|
|
- e-mail
|
|
- IRC
|
|
- Matrix/Riot chat
|
|
- Diaspora
|
|
- Xonotic ingame chat :) We actually have pretty serious discussions in that game.
|
|
|
|
> Question zero: What is "SW" ?
|
|
|
|
software :)
|
|
|
|
> I've seen that pure C software renderer. In fact, I've spoken with its author.
|
|
|
|
It's truly impressive, I think in the video it even has linear filtering for the textures? Full HD on 60 FPS with this stuff must be running on a small supercomputer, or perhaps use some platform specific hacks? I dunno, the performance is awesome as hell. Anyway, the goal for S3L wasn't maximum speed, it tries to be platform independent and simple, which kills some potential performance boosts.
|
|
|
|
> (DDA) which is a floating point method.
|
|
|
|
I know DDA, it can be done without float (almost anything float can be done with just fixed point). I use it in raycastlib to trace rays.
|
|
|
|
At first I used DDA in S3L too, but sincerely I didn't figure out how to make that respect the rules of rasterizing adjacent triangles, i.e. to have no holes or overlapping pixels on triangle borders. I implemented the top-left rule my own way. Perhaps it can be done with DDA or some algorithm I don't know of, I didn't do much research actually.
|
|
|
|
> Yes I saw your game anarch
|
|
|
|
Yes, it's nearing completion now. I actually want it to be not just a game, but also a potential research/educational tool, a toy for hackers, a basis for other projects etc.
|
|
|
|
> physics engine I and a coding group (The C Chads) are designing. We want to *only* depend on SDL2 and an available C99 compiler.
|
|
|
|
This is very awesome, +1.
|
|
|
|
> Yes, all the software i'm writing is free software. The physics engine will be CC0.
|
|
|
|
You're my guy, I am actually planning a CC0 physics engine in the same style as S3L/RCL, but currently am busy with many other projects. I am so glad that someone is doing this stuff.
|
|
|
|
> Don't get me wrong, your rasterizer is *BEYOND* cool.
|
|
|
|
Thank you :)
|
|
|
|
> I'll be straight with you. How could I implement proper near plane culling into your model renderer? Particularly, how could I get the barycentric coordinates interpolating correctly?
|
|
|
|
|
|
|
|
|
|
I did some digging around in small3dlib.h while writng this email. You render unsorted on line 2589, in drawScene (Which happens to be the only functionality of your renderer i'm interested in, so I ain't worried about sorted)
|
|
|
|
> A near plane clipping will create at most two triangles from a single triangle (If one of the points fall behind the near plane)
|
|
|
|
```
|
|
|
|
________
|
|
\ /
|
|
\ /
|
|
____\ /
|
|
\/
|
|
|
|
|
|
```
|
|
|
|
|
|
Example implementation of near plane clipping from a fairly well-known coding 'tuber's implementation (Albeit in C++, not C99, and he releases under a modified BSD3. We can both agree, not acceptable for my use case)
|
|
https://github.com/OneLoneCoder/videos/blob/master/OneLoneCoder_olcEngine3D_Part3.cpp
|
|
(Line 322, int Triangle_ClipAgainstPlane)
|
|
If you wanted to clip the triangle and have the barycentric attributes come out correctly, you'd need to interpolate them for the new vertices, which would require a change in how S3L_drawTriangle works.
|
|
|
|
It'd be neat to *have* this interpolation correct, however it isn't necessary as we plan on doing flat color models. As long as the triangle index and model index passed to S3L_drawTriangle are the same for both clipped triangles (or the one, smaller triangle) it's 100%, totally fine. We'll be able to get ahold of the same normal, and do the same dot product, and get the same resulting flat color for the entirety of the triangle (And per your recommendation, use a per-triangle cache)
|
|
|
|
If you came up with a patch yourself for this specific case (Where we don't care about the barycentric attributes, but we want proper near plane culling) i'd switch your renderer immediately. *AND* I would ditch the GL implementation
|
|
|
|
Our renderer would already be using S3L_FLAT so you could even write a check to see if this attribute was enabled and provide a compiler error if S3L_CORRECT_NEAR_PLANE_CULL was enabled but S3L_FLAT was not... or forcefully enable it, which seems to be the convention of your library.
|
|
|
|
Thanks,
|
|
Gek |