[Open-graphics] What I think is needed.
nicolas_capens at hotmail.com
Wed Dec 1 18:43:30 EST 2004
I'm only trying to help...
> I'll have a look at it when I'm done with the hundreds of emails I'm
> getting, but you must realize that it's an unfair question.
I understand about the hundreds of e-mails, but my challenges aren't all
that unfair. Sorry for repeating but you -will- encounter problems like
> I don't know your code. If I'd written it (like I will develop the FPGA),
> then I would know where to start looking.
Frankly, the code in my article is derived directly from the formulas (the
half-space functions to start with). The rest is just straight-forward
implementation. I would even dare to say it's almost like pseudo-code, very
mathematically defined, it just happens to compile correctly on a C++
compiler. The bugs are -not- implementation related but math/algorithm
> Additionally, I'd have screenshots, an understanding of the scene geometry
> (is your earth flat or curved?), etc. I would put it through simulations
> and develop tests of my own to isolate the problem.
Yes, a screenshot would be fair. Coincidentally, it's the scene from my main
webpage: http://sw-shader.sourceforge.net/main.html. I could provide
screenshots (or even an executable) of the exact problems too but it's not
going to help you further. The first problem was that sporadically strange
colored 8x8 pixel blocks appeared at the horizon, when just looking around.
The second problem was that single pixels appeared in the terrain, also with
all kinds of color. The artifacts only showed on polygons that were nearly
flat, little more than a strip of pixels.
I'm very serious, the cause of these problems can be deduced directly from
the math and algorithms used in my article. The second one is harder, but
I'll give one more hint: it's related to the way how colors are interpolated
over the polygon. That scene uses modulation with the diffuse interpolant
for lighting. The actual problem still originates at the rasterizer level.
Still feel free to ask more information, but I hope you'll at least start
giving it a try. I'll guide you in the right direction if you take the
effort of analyzing these problems.
> Now, it is sometimes the case that customers bring up bugs which we cannot
> easily replicate here, and it is often the case that I fix bugs through
> direct examination of code.
> So what you're asking for isn't unrealistic... but it IS unfair.
The only reason I can think of that it's unfair is that you haven't got all
the experience in graphics yet. I'm not doubting your intelligence and
certainly not your expertise at hardware design. In the worst case, just see
my challenge as a 'fair' warning of the complexities you'll encounter on the
way. If you can spot the problem or at least show the perseverance to want
to solve it and get close to the source I will be truely impressed.
Please forgive my scepticism. I hope you understand that it's a natural
reaction. It happens in a lot of open-source projects, and it would really
help a lot of you could prove yourself in one way or another. I'm giving you
that chance and I hope you grasp it with both hands. Don't do it just for
me, but for yourself and everybody interested in this project. I truely hope
you may succeed.
> I did have a quick look at your page, and it does look pretty awesome.
> There is SOME code there that I would have done differently, but perhaps
> you are relying on the optimizer to do certain non-obvious things.
Well, like I explained above, the code is intended to be very 'neutral';
very straight-forward, mathematical. So yes it relies on some common sense
for an actual efficient implementation and/or an optimizing compiler. In
fact my own implementation is purely in assembly, using MMX and SSE, but the
math remains the same (except for the bug fixes of course). For a hardware
implementation I'm sure some other approaches are more optimal.
More information about the Open-graphics