[Open-graphics] What I think is needed.

[Nicolas Capens]

Hi Timothy,

> <sigh>

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 
this.

> 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 
related.

> 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.

Thank you.

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.

Best regards,

Nicolas