PR Update

Wow man, that is so awesome...I must say congrats on your work with Power Render, Im definitely considering it for my 3D project. Ok one simple question, I know anything is possible, but will be be possible (without heavy modification to code or whatever) that say for example you had a ship flying like the one in this pic but it decides "hey I want to go into space", so it goes up (this is in a view following the ship or inside the cockpit) and you eventually get into space while seeing the planet get smaller and smaller as u go farther out Or would I have to make 2 "seperate" types of whatever (one land, one space)

Thanks for the input

Later,
Scott

Again, outstanding job!

You could do it with a clever fade between each system. For example once you fly up high enough your coordinate system would change to allow to outer space objects all over the place.

I know it''s kinda late, to be asking for features...

But a while back, Iwas trying to create a UI and using overlays doesn''t cut it.

Is it possible to have some type of rasterazation feature, to blit bitmaps on screen using colorkeying and alpha blending also etc...

That isn''t a static display is it?
What kind of FPS?

In the top left corner it says 14 fps. It''s dealing with 147456 triangles for the landscape, and a few thousand more for the ship, character, water and sky.

I''m not even using triangle strips on the terrain yet, so I''m expecting even more speed with such a high visibility range.
An actual game would probably not use that high since you''d have to draw more objects in the distance as well.


"Is it possible to have some type of rasterazation feature, to blit bitmaps on screen using colorkeying and alpha blending also etc... "

Maybe you can use DirectX Blt functions directly to paste something over the rendered image? I haven''t attempted it personally. Overlays are good for things that you need translucent effects instead of just color keying.

Oops. I missed the small print.

BTW, it looks very realistic. Congrats.

But overlay arent good enough for ui! any hoo the Terrain looks good

>It''s dealing with 147456 triangles for the landscape
imho it''s too much,
in this level of detail (hill on the right is not so smooth)
it should be no more than 10000 triangles!!!

10,000 maybe if you''re using a card without hardware T&L

Right now I''m pushing way more polygons than you really need, so I can optimize it. If it''s maxing out at 60 fps then I can''t tell if something is getting faster.

The engine is designed for hardware T&L and future cards, and doesn''t use any terrain LOD. This means you can give the card all the terrain vertices and no per polygon processing is done to figure out what it should be drawing.

Considering that ATI and Nvidia already have T&L cards available, Matrox and 3Dfx should have next year, I think it''s the right way to go.

I agree with Chris,
Terrain LOD routines are expensive CPU time wasters, and with a Good T&L card, it is actually far quicker to just throw the terrain data at the card.

I am also looking ahead, with NVidia creating the cards for the XBox, I imagine they will end up with a pretty huge market share on PC''s as well.

Cheers
Darrin

60fps is not so much,
remember that this is only a terrain,
what about objects, characters and fx ???

anyway there are few algorithms to do terrain with lod
optimized for T&L..
imho you''re just too lazy to do something more than just
brutal-force algorithm...

example from my project:
i need to render terrain with big (about 1000 meters) radius,
for simulation of some sophisticated arrangement..
let''s see:
quad = 1 meter x 1 meter (it''s not too much detailed)
radius = 1000 x 1000 = 1,000,000 quads !!!
what T&L card can handle it ?

But how much of that area is visible in one frame?
The beauty of my engine is that the memory used for polygons is independent of the landscape dimensions, unlike ROAM which needs to have the entire world preprocessed. The memory required depends on how far you can see in the distance and the actual world can be much much larger.

It is not a brute force algorithm and there are some things going on behind the scenes that the user is not aware of (quadtree, sliding window, shadow paging). The engine also does realtime soft shadows using a clever texture paging system. This is something I''ve been working on for a long time. The landscape engine was originally designed in 1996 and has been tweaked every year since. It existed before the engine was even called Power Render. It''s not just a simple terrain engine with a few polygons thrown together.

Everything in that screenshot is being rendered by hardware transforms. The only visibility processing required by the CPU is a few bounding box tests and a quadtree traversal. If I had to use dynamic LOD on the terrain and traverse a tree down to each polygon it would be much slower, not to mention use a lot more memory.

One of the reasons for keeping the visibility lower is so you can have more objects lying around the landscape. If you can see miles in the horizon you''ll need to draw thousands of objects. I''ve been doing a lot of playing around and at one point had 70,000 polys worth of trees. This depends on the game of course. If you''re making a flight sim the visibility would be high compared to an outdoor RPG where you want highly detailed environments to wander in. Take a look at other outdoor games like Tribes 2 and Halo and you''ll notice how sparse the trees are. I haven''t forgotten about objects and will be working on a dynamic object LOD algorithm that works with hardware transformation in the future. Right now I have a system that switches between different object representations that works pretty decent.

Visibility also depends on scale of the other objects compared to the landscape. If the objects are small and slow, you can flatten out the landscape and distances seem much farther.

Oh, and if I was lazy I wouldn''t be making an engine in the first place. I was going to change my engine over to a dynamic LOD terrain but wasn''t impressed with any of the existing engines out there and I would have to add some limitations that are currently not present in my engine.
I also hate ground that moves from the LOD algorithms. It''s not natural.

Chris

ok i''m sorry... it''s not a brute force method,
but terrain rendering has O(radius^2) complexity, and that was my point...

about laziness:
i think maintaining the same renderer architecture for five years is comfortably,
but it causes your engine obsolete..
for example i don''t think rendering methods are good solution:
in today engines when you add one feature, it should not break another, with rendering methods it''s very hard to obtain...
i was trying to make a nice underwater simulation, and i end up with tons of new (not portable!!) rendering methods...
i know more examples that proves PR obsoleteness, but that''s not my point...

anyway I agree that every terrain algorithm has good and bad points.
it''s very hard to do terrain which can be used in every project,
and your terrain is dedicated to adventure games where camera is not going too high...
i''m working on simulator, where terrain lod is a must, so i won''t use your terrain..

another thing is aliasing, if your triangles are too small it''s not looking good,
rendering bigger lod-ed triangles may increase visual effect..
(ok i know that new hardware will support antialias,
but realtime antialias filtering has some limitations)

anyway, for special usage your terrain is quite good solution..
even power render is not so bad, of course only for limited purposes..

Best regards,
Tomkh

I haven''t kept the same renderer for 5 years. I''ve had software rendering, Glide, OpenGL, and Direct3D support. The API calls are mostly unchanged because I planned the engine out well ahead of time.

I''ve add many things to the terrain engine other the years. At first it started out using a set number of tiles. Now it uses a unique texture covering the entire world. This year I added in shadows, quadtree visibility, and hardware transformation. The biggest challenge in writing an engine is keeping it up to date with the latest hardware capabilities. I have done that, and that''s why PR still exists after 5 years.

PR only supports Direct3D rendering now, so saying that rendering methods are not portable is irrelevant. In PR 2.6 you can write different code for each rendering method on each platform.

Of course every engine is more suited for one kind of game. You don''t make a flight sim engine and then make a first person shooter with it. Flight sims where you''re high above the terrain are a different breed. With a low terrain engine there are many other uses, like RPG, RTS, driving, shooter, and so on.

Chris

>> In PR 2.6 you can write
>> different code for each rendering method on each platform.
that''s why i called it not portable... but i only mentioned about this...
as i said:
>> in today engines when you add one feature, it should not break another,
>> with rendering methods it''s very hard to obtain...
what would you say about that ?

it''s just i have a different point of view about what engine should be...
nowadays engines should be very isolated from main project,
because keeping it up to date is almost impossible!
of course you can do it, but imho it cost too much and causes serious limatations to engine features..

i think you''re too blind to bad points of your "glorious" engine !

that''s way PR is only good for amateur projects,
If you don''t agree,
give an example (title) of existing game (that achieve success)
or serious software company that uses your engine ???

Tomkh

Most people will never make their own rendering method because I''ve provided a ton of prebuilt ones. You''re complaining because I made it possible to go low level and do things that I never thought of? Since the full source code costs more I think most people would appreciate the ability to this.

If you break something by adding a new rendering method, that''s your fault not mine. You can easily break an application by calling a Direct3D render state halfway through a program since PR only sets default values at the beginning. One of my goals for PR was to make it as open as possible without giving out the source code for everything. This way new users don''t have to deal with any of the low level stuff, but once they''ve been using it for a year or so they can do whatever they want without waiting for me to make a new version.

There are different levels of 3D engines. The highest level ones provide you with a level editor and are ready to have custom objects slapped into it and use predefined AI. Power Render is not like that. It''s an API that is ready for someone to build a higher level engine on top of it.

I''m doing this right now with Landscape Studio 4 for outdoor games, and probably will try indoor stuff later next year.

As far as games made with PR.. I have no idea. I''ve had thousands of registered users over the past few years and I don''t keep track of what they''ve created.

Finally, I wish people would give me specific examples of how to make the engine better. Just saying "when you add one feature, it should not break another" doesn''t such much. I don''t even know how that would apply to PR.

There seems to be a common misconception that PR is a complete game engine like the quake 3 and not an API like it is.

Gary

Don''t let these critics get you down Chris. PR is a shining example of a quality *multi use* 3D API. PR is one of the most advanced, and affordable, 3D APIs that doesn''t require advanced knowledge of DirectX or Win32 lowlevel programming. Keep up the good work!

-Rich