try it yourself,


http://www.voidware.com/prizm/p3dv1.0.zip

copy the add in and the 3 model files to the top level prizm directory. run the app and select the model. there are three shaders, flat, smooth and wire.

performance could be better. im still doing additional screen copies which kills the frame rate. the teapot is 3000 polygons.

-- hugh.
very nice! care to share details of the rendering engine?
Very impressive indeed! I too would love for you to share your code, particularly if I might impose upon you to see how applicable it might be to the long-suffering Graph3DP.
That's really awesome. I need to try this on one of my Prizms later.
Spenceboy98 wrote:
That's really awesome. I need to try this on one of my Prizms later.
Have you also seen AHelper's previous work with 3D on the Prizm, including a general 3D engine and his 3D checkers game? This goes for the OP, too.
Great work, it looks like you even managed to implement back-face culling!
KermMartian wrote:
Spenceboy98 wrote:
That's really awesome. I need to try this on one of my Prizms later.
Have you also seen AHelper's previous work with 3D on the Prizm, including a general 3D engine and his 3D checkers game? This goes for the OP, too.


Yeah I have. I like the checkers game.
This....I like this....Now I am curious, how would I begin making 3d shapes for this program? I'd like to do some tests of my own!

I have noticed that hitting the AC/ON button permanently ruins the simulation and I must re install it.
Hi,

let me try and answer some questions...

i'm happy to explain how it works if anyone wants to ask anything specific. but here's a quick summary of operation:

i'm currently working with a simple model definition format. my model files are a binary version (for compactness) of Wavefront obj format. However, i'm only loading vertex and face data. faces can be triangles or quads. It would be fairly easy to add simple colour to face data, although i can't handle textures.

All calculations are performed with 16 bit fixed point arithmetic. no floats are used. consequently the numbers in the model files are 16 bit ints. I convert a wavefront obj model by centering and normalising to +/-32767.0, then save as 16 bit int.

there can be multiple models in view. for each frame, i transform the vertices of each model according to a combined orientation and view transform, then adjust for perspective.

face visibility is then determined by calculating the screen space area (ie using the transformed vertices). if negative, then not visible. potentially visible faces are then sorted by Z depth.

shading is then applied. the shading type is actually per face and not for the whole model. visible flat shaded faces are coloured by face normal DOT light direction + ambient + face colour. visible smooth shaded faces are Gouraud shaded.

to Gouraud shade, vertices have normals and each vertex normal is shaded according to; vertex normal DOT light direction + ambient. later the scan line converter will interpolate the vertex shades to apply gradient.

the visible faces are then rendered in the order far to near. their screen space vertices are scan line converted after clipping.

other questions...

yes sorry, once you quit (AC), you have to run another add in before it will start, otherwise it just goes back to the stopped state. is there a proper way to quit an app so this doesn't happen. i will fix it.

i might eventually release source code, after a major tidy up. at the moment i've had to throw in my own hacked versions of basic things like fopen/fread/malloc etc. These all seem to be ropey or missing from the PrismSDK. I've been advised there's a more up to date version somewhere. can someone point me at the right place.

ideally, i'd like to take out my hacks and use the standard libc functions. it would make everything a lot cleaner.

thanks for your comments,
-- hugh.
Ah, so you just draw the faces by depth sorting, not using a z buffer? What control can programs have over the renderer? The renderer that I use lets you define custom fragment and vertex shaders, letting you do per-vertex shading, texture mapping, bump-mapping, and other fun things at nice quality at the cost of speed for the required vertex math (which _could_ be sped up a bit by using the IL cache).

Also, do you know the FPS when rendering full screen?
hugh9860 wrote:
yes sorry, once you quit (AC), you have to run another add in before it will start, otherwise it just goes back to the stopped state. is there a proper way to quit an app so this doesn't happen. i will fix it.


Yes, there's a better way. The idea is that the code never stops. You just use GetKey, and when the user presses MENU, it will be taken to the menu (the add-in code will be paused), and if it reenters the add-in without launhcing another one, the code will resume. Of course, GetKey can be a bit slower than reading the keyboard matrix directly. There are some hacks to bypass this (i.e. detecting when Menu is pressed in your custom key routines and then doing a GetKey: this is what games like Raptor and Pong do).
are you using the Markus Trenkwalder renderer. i've had a look at the code and it's nicely designed and flexible. it's certainly better than mine in many respects. for example, my render is a monolith; there's no separating out of vertex and fragment shaders. i have no control over what it does!

This, of course, limits me to what it does rather than being an architecture to apply shaders. However, the general purpose approach, always has its cost.

for example, there is a significant amount of overhead in both vertex and triangle processing.

You really want to transform the whole vertex set in one hit, rather than working with small bundles of vertex cache. When the cache is full, the attributes are rendered. This means you have no chance of working with the global processed attributes of a model. For example, z sorting could not be performed here. To fix the visibility problem, you're going to need a z buffer which is memory, at least, the size of the viewport. This also hurts as it's a per-pixel comparison and an additional memory hit.

The triangle processing including the fragment shader is a another area of significant overhead. You get quite a stack of processing before hitting the fragment shader because it has to do things in a general way. I have a rather nasty triangle scan converter which interpolates what it needs as it goes, rather than making calls out per pixel.

i would say the shader architecture, approach is much better suited for hardware implementation than software.

However, i do quite like the Markus Trenkwalder renderer. If it's fast enough for my purpose, maybe i'll switch to it.

BTW, my purpose is to render graphs and plots in 3D. my idea is to generate a 3D model of the plot in question and then render it as an object. There would have to be some kind of zoom refinement (LOD). There would also be axes and tick marks, which would probably also have to be 3d objects. text could be bill boarded, but it would have to be scalable.

regarding FPS, i don't know. what timing calls can i make to measure this. currently i've just been looking at it.

-- hugh.
hugh9860 wrote:
BTW, my purpose is to render graphs and plots in 3D. my idea is to generate a 3D model of the plot in question and then render it as an object. There would have to be some kind of zoom refinement (LOD). There would also be axes and tick marks, which would probably also have to be 3d objects. text could be bill boarded, but it would have to be scalable.
Sounds like you're planning to steal my thunder. Laughing I need to get back to Graph3DP one of these days and finish off the rotation stuff once and for all. Perhaps I should pick your brain about rotation, since I seem to be having so much difficulty wrapping my head around it.
Well Kerm, you could always shout at it screaming "Turn darn you TURRRRRRRRRRN" hoping for the best. I find that sometimes due to random chance it helps my computer out. What are you making this graph3d thing in?
No, actually, i have no intention of doing the same as another project.

my main focus is going to be using 3D to render 2D graphs and charting. for example, charting and data visualisation in, say spreadsheets have that 3D look. The 3D is fake 3D, but what would it look like using real 3D (ie per pixel lighting) - a lot better i would hope.

Most of the time what people need is quality visualisation of a simple function. I think the built in graphing [on the Prizm] could be done a lot better, for example.

Naturally, if i'm using 3D presentation, the obvious thing would be to allow 3D plots too. These can look impressive, but to make them really useful would take a lot more additional work.

going back to the consideration of the rendering system. i'm interested to try to make my approach work with OpenGL ES, because in all but calculators, software rendering is dead. even the most pedestrian mobile device today has considerable 3D capability. I'd like to target those too.

This is a good reason to switch to the shader based software rendering some of you guys are using; it's model of doing things is closer to how OpenGL works.

Of course, i'd like to get something good going on the Prizm too. It's constructed as a calculator with a proper keyboard - something mobile devices sadly lack.

-- hugh.
Very nice. Are you going to make a prizm version of reckon?
Hello Flyingfisch,

yes, i'd quite like to move foward onto a newer platform with a bigger screen.

However, it's more than just having more pixels and colour, i also want to make use of the faster CPU, memory and so on. I'm hoping to add in a lot of new stuff i never got round to before.


thanks for your interest,
-- hugh.
hugh9860 wrote:
Hello Flyingfisch,

yes, i'd quite like to move foward onto a newer platform with a bigger screen.

However, it's more than just having more pixels and colour, i also want to make use of the faster CPU, memory and so on. I'm hoping to add in a lot of new stuff i never got round to before.


thanks for your interest,
-- hugh.


cool. It seems that KermM is having some trouble with Graph3DP. maybe you would like to tell him what you learned with the 3D graphing function in reckon?
the reckon 3D plot was not finished because i never got around to putting on axes and labels. it looks ok, but you can't really use it for tracing out values, for example.

Nevertheless, my approach was the same as i intend to do again, which was to treat the problem of the visualisation as separate from the calculation. The function is sampled over X and Y, then a 3D mesh generated internally and passed to a rendering engine to display.

eventually, i was planning a feedback loop where the mesh could be refined depending on the view. Actually, there is a button to increase the sample density of the reckon 3D mesh, but in practice it makes everything look worse due to screen size limitations.

i don't have any 3D picking in my 3D code. This will be need to implement the aforementioned tracing and display of values over the surface so the user gets to examine the values of parts of the functions.

After that, it's a question of what you want it to appear like. use of colours, shading etc. sometime flat and/or wire shading looks good for technical plots. in my tests so far, i'm just using intensity so i'm limited to 0-31 shades, despite the 16 bit colour depth.

Perhaps a gradual change of colour (eg with height) would look nice and make better use of the colour space. a bit like the mathematica 3D plots, which i think look quite nice.

Anyhow, my main suggestion is to transform the plot problem into one of the display of a surface manifold and its presentation.

other than that, i'm still learning the best way too.
-- hugh.
I think Kerm's problem was trying to rotate on multiple axes. I know that reckon can not only rotate on all axes, but you can also move the graph around the screen (i love that feature)
  
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.

» Go to Registration page
Page 1 of 2
» All times are UTC - 5 Hours
 
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

 

Advertisement