um, i''m not gonna get mad, let''s throw that out first. but, how can atom code be faster than texture code? each texel has say, 32 bits assigned to it. that''s 4 bytes. each atom would have subatomic structures which would take up more than 4 bytes per atom. unless, you DO just assign just color, which reduces to the same effect as a texel. however, if you rendered atoms as "colors" to the screen, that would actually be more processor work, because, a single texel on a texture could possibly take up a range of pixels on the screen, which would save some calculation time with such algorithms as run length encoding for the texel. whereas, these individual atom colors would have to be rendered individually without any encoding.

a2k

does code not run faster than image data. im sure that you have seen code based animations have you not.

"Why does my life have to be so hard in every world?"

Nanami Jinii;El-hazard

either way, you''re gonna have to throw it to the screen. why process more than you have to in the code? there would be less image data than "atomic" data structure data, so it would be faster to process.

do you mind if i post your idea in the general game programming forum and ask them what they think?

a2k

I dont mind at all. I realize that the computer would have to process more data for atomic surface coding but image data takes more computing cycles that math statments. floating points are complex mathmatic statments but the real ocmplexity and strain is updateing the image data that they are surfaced with. am i wrong?

"Why does my life have to be so hard in every world?"

Nanami Jinii;El-hazard

thanks for going to bat for me man.

"Why does my life have to be so hard in every world?"

Nanami Jinii;El-hazard

Just a point,

Building at the atomic level...is that building or rendering? I can''t think of any reason why I''d waste my time "building" at the atomic level

The would be ridiculous.

However...rendering, well as I posted elsewhere, rendering with anything other than polys is for the near future out of stretch, and for the count, I don''t think I''ll see "atomic" rendering since there will always be techniques available to render quicker without resorting to such a low-low-principal on construction.

Incidentally, polygons are already running the problem of massive overdraw figures already. (polygons you don''t see) Since currently popular rendering techniques use a z-buffer to prioritise poly draw, the problem is all polys is the scene are drawn...

...remember the PowerVR? Well that used HSR (Hidden Surface Removal) It had a 32bit z-buffer and was able to remove polys from the render pipeline which were not viewable. This sped up the rendering process and reduced overdraw.

Rendering a forect is difficult using purely a z-buffer based rendering system as everything is calaculated, prioritised regardless of whether is in viewable to the user. Even then, there is always a way around it...

I''m not saying we''re "stuck" with polys, it''s just that an atomic rendering system, is not practical (enough with a fast enough CPU, enough Memory etc), there are other ways, and at any rate, as already mentioned by someone, you could always approxminate the "atom"...

I''ll stop typing now...

www.stephen-hawes.co.uk