• Advertisement

Archived

This topic is now archived and is closed to further replies.

Software Rendering and Engine Scalability

This topic is 5059 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Since I''m developing my engine on a computer whose video card has no 3D acceleration, I''m trying to scale my engine as far across the spectrum as possible (I want the pretty effects of shaders, yet still have the game run in a 500 MHz Celeron). Thinking about how I''d implement shaders on such low-end systems, I realized that I didn''t have to implement them at all, since my engine design encapsulates the shaders within the graphics renderer, so I could theoretically swap in a renderer that doesn''t use shaders. Since I was planning to write some kind of software renderer, I thought that that could be the renderer for systems without programmable pipeline support. Looking through previous threads about software rendering, the general consensus seems to be that I don''t need to write one, and if I really needed one, I could use one written by someone else. If I was going to write one, I should use it to do something special, not simply emulate the Gouraud-shaded polygon-pushing that video cards are designed for. I was thinking of either writing some sort of raytracer, or something specialized for occlusion queries. But is it worth doing a software renderer at all?

Share this post


Link to post
Share on other sites
Advertisement
quote:
Original post by mittens
It''s good to do a software renderer if you''re interested in doing it for the learning experience; though it serves no practical purpose whatsoever.


Tell that to those crazy retards at Pixar.

Share this post


Link to post
Share on other sites
Some day we will have cards running almost normal programs,with branching,loops,and recursion. So hardware rendering will be replaced with software rendering.
By definition,hardware rendering = rendering with fixed pipeline.
So now we have a lot of SW rendering done on GPU.
HW rendering is faster than software rendering,because it does not have to interpret commands,but it can''t achieve all effects.
And we need quality,not throusands FPS.

My SW terrain renderer with many effects

Share this post


Link to post
Share on other sites
quote:
Original post by Dmytry
And we need quality,not throusands FPS.


Indeed. Though I disagree with your definition of ''hardware rendering'' - I''d say it''s all the rendering work done by dedicated hardware (i.e. the graphics card), and has nothing to do with whether it''s fixed pipeline or programmable pipeline.

WRT the original question: I''d say that a software renderer is sometimes useful for generating low-resolution image data that you then need to process on the CPU - like occlusion maps, or something. It can be faster than all the changing render targets and pulling stuff back over the AGP line.

Share this post


Link to post
Share on other sites
But CPU also is a hardware.So any rendering are hardware rendering.
Only in graphics,CPU are used more-or-less efficiently.
Hehehe, for servers, 10 times faster CPU it's 10 times more nested protocols and 10 times more interpreted scripting. Just imagine game that,like server, stores the world tree in SQL database and uses SQL queries to get objects(on the fly),etc,using TCP-IP to talk with 127.0.0.1 via HTTP requests to PHP scritp .Same for other usages of computers.

So cpu are mostly used in graphics(edit2: and of course scientific calculations,but that's uncommon usage),and other common applications just takes as many power as they have.

[edited by - Dmytry on April 12, 2004 7:38:55 AM]

Share this post


Link to post
Share on other sites
Dedicated hardware.

ded·i·cat·ed ( P ) Pronunciation Key (dd-ktd)
adj.

  1. Wholly committed to a particular course of thought or action; devoted: a dedicated musician.
  2. Designed for a particular use or function: “The satellite beams the information down to Earth, where it is sent through dedicated telephone wires to the Space Telescope Science Institute” (Boston Globe).


[edited by - frostburn on April 12, 2004 8:20:35 AM]

Share this post


Link to post
Share on other sites
I want to write some sort of software renderer to learn from (and for bragging rights), so.. any suggestions whether I should do a raytracer for low-end systems, or a simple software renderer for say, occlusion culling?

Share this post


Link to post
Share on other sites
I guess it would depend at where you stand today (technical expertise).

A few years ago when I first started trying to learn graphics programming I wrote a raytracer. It doesn''t really teach you about the current scanline pipeline, but you still learn about lighting and shading and can make some cool pictures, might as well go for it. The advantage is that raytracers for the most part are pretty simple.

Share this post


Link to post
Share on other sites
quote:
Original post by Dmytry
Some day we will have cards running almost normal programs,with branching,loops,and recursion. So hardware rendering will be replaced with software rendering.
By definition,hardware rendering = rendering with fixed pipeline.
So now we have a lot of SW rendering done on GPU.
HW rendering is faster than software rendering,because it does not have to interpret commands,but it can''t achieve all effects.
And we need quality,not throusands FPS.

My SW terrain renderer with many effects

Nice screenies man.

Share this post


Link to post
Share on other sites
It is worth it writing a software renderer. But beware that it will take you -years- to get really useful results.

I have been working on my swShader renderer for the past few years. It uses dynamic code generation to avoid branching in the inner loops, and supports DirectX 9 shaders. Currently I''m working on a DLL interface.

Share this post


Link to post
Share on other sites
Yes,it takes long time. My renderer are about one year old ,and many things to be done.
(i have to make exponential atmosphere(nearly ready) ,heh,i have volumetric fog but i don't have exponential atmosphere. Then i need to make water, more realistic cloudshapes,etc,then GUI. Lot of work(but more than half are done).
And before starting i already wrote simple 2d graphics lib(pretty ugly,but i still love my floodfill routine that works
at > 100 FPS :-).

As about shots,yet another one,recently uploaded:
http://dmytrylavrov.narod.ru/images/screenshots/voxel/album4/503.jpg
"hypertexturing"
(my hosting dislike direct linking,so you should copy that address,click on previous link,and then paste that into browser address line.)

[edited by - Dmytry on April 12, 2004 5:39:33 PM]

Share this post


Link to post
Share on other sites
I''m not really looking to make a full-fledged software renderer, just a basic one. Like I said, it''s going to be a renderer DLL for low-end systems, so I don''t think I''ll want (or even be able to support) too many fancy effects.

@C0D1F1ED: Yeah, I found links to your project browsing through old threads, and I have to say that that''s pretty insane. It must have taken you years to get it this far..

@Dmytry: Saw your page too, your terrain is just amazing. Now if only there was some way to get it above 3 FPS..

Share this post


Link to post
Share on other sites
I think,if it''s fast enough to upload textures from main memory to card,i can render images to textures (with back sides of mountains too) and then use low-res landscape and billboards to approximate it for seconds ,while rendering next panorame.And when camera are too close and moves too fast,motion blur may be used to hide all artefacts.So it may work at >20 fps.

Also,camera movement should be predicable enough(true for flight-simulators,position for next seconds are known very precisely,no matter what keys player will press)

Share this post


Link to post
Share on other sites

  • Advertisement