Gammon Software Solutions forum

Gammon Software Solutions forum

See www.mushclient.com/spam for dealing with forum spam. Please read the MUSHclient FAQ!

Entire forum
Programming
General
Ray tracing, DirectX, OpenGL, graphics, etc.

Home \| Users \| Search \| FAQ
Username:	Register forum user name
Password:	Forgotten password?

(New message)

Subject:	Ray tracing, DirectX, OpenGL, graphics, etc.
Name:	Your forum user name. Register forum user name
Password:	Your forum password. Forgotten password?
Message:	[quote=David Haley] [quote]No actual OpenGl rendering.[/quote]What exactly is "actual OpenGL rendering"? Why are the examples you gave not considered "actual" renders? [/quote] Message to be posted (in English, please).
Forum codes:	Check this if your message uses 'forum codes' or templates (auto-detected for new posts). Forum codes Templates

Save this message ...

Subject review (reverse sequence)

Pages: 1 2 3

Posted by

Ked Russia (524 posts)

Date

Sun 11 Mar 2007 10:55 PM (UTC) [ quote ]

Message

That "OpenGL rendering" is the thing that's been keeping me perpetually confused by this thread. Do you mean by that using programmable shaders on the GPU? I am only aware of the dichotomy between "software" and "hardware" rendering, but not "POVRay" and "OpenGL" rendering.

Posted by

David Haley USA (3,881 posts)

bio Moderator

Date

Sun 11 Mar 2007 10:19 PM (UTC) [ quote ]

Message

Quote:
No actual OpenGl rendering.

What exactly is "actual OpenGL rendering"? Why are the examples you gave not considered "actual" renders?

David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org

Posted by

Shadowfyr USA (1,774 posts)

Date

Sun 11 Mar 2007 10:04 PM (UTC) [ quote ]

Amended on Sun 11 Mar 2007 10:07 PM (UTC) by Shadowfyr

Message

Hmm. May have to "partly" eat my words:

http://www.daylongraphics.com/other/povray/patches/

It includes a OpenGL patch for an unofficial version that, at least partly, supports using OpenGL to render POV-Ray scenes. However, its not going to produce "quite" the same quality. Its also "incomplete", without proper texture support for solid rendering (the final scene result), etc. Basically, you get (wireframe), full render + wireframe, or full render. No actual OpenGl rendering.

Note, it has a statement on the CSG issue, which imho is the "biggest" problem with using non-raytrace. Specifically, he states:

"CSG is by its very nature almost trivially easy for a raytracer to do, and consequently, almost impossible to get a mesh equivalent."

This is the crux of the problem. If you want to limit the amount of junk you send down the pipe, you need to use primitive, but if you use them, then you are stuck doing lots of extra work either a) using software tracing or b) using various methods to attempt to approximate the effect of the CSG, so that you get the same result in a mesh. The time you gain by not rendering is lost again in generating the mesh itself. And a detailed scene might have 50+ objects you need to CSG to produce the final result.

Another interesting animal:

http://www.slimeland.com/raytrace/

Written in JavaScript.

Hard to find a link, but some people have taken data from things like WoW and rendered them in POV-Ray, with much improved results. In fact, finding a link is driving me nuts. lol

Anyway, think this is about exhausted as a topic. Short of coding a system and then fiddling with just what you "need" to make it all work, its hard to predict if it will work, or what limitations end up getting in the way (especially with bandwidth if someone is not using broadband).

I do hope that one day this sort of stuff will become possible using a card though:

http://www.ignorancia.org/en/index.php?page=Introduction

main {
__if (Schrodinger_Cat is Alive or version >= "XP"){
____if version = "Vista" then Performance /= Number_of_Cores;
____call Functional_Code();}
__else
____call Crash_Windows();}

Posted by

Nick Gammon Australia (18,800 posts)

bio Forum Administrator

Date

Sun 11 Mar 2007 01:18 AM (UTC) [ quote ]

Message

Exactly. It is like watching an old black-and-white movie. After the initial shock of not seeing colour, your mind adapts, and you get involved in the plot (if it has one). In fact, the monochrome look can have an atmosphere of its own, and some recent movies have been shot in monochrome (eg. Schindler's List).

However if Hollywood tries to "improve" an old black-and-white movie by "colourizing" it, for me at least, the effect is usually worse. Now, since colour is present, I expect it to be good colour - often it isn't. Also, you notice problems in the process where faces are slightly gray. And you expect colour to be used "properly", eg. for dramatic effect.

It is the same with attempts to do photorealistic rendering - if it looks like we are trying to render "real" scenes, and "real" people, then we are raising the bar of expectation. We also expect smooth action. At present, as far as I can see, we don't really have that.

Some of the modern rendered films look very good, and the people in them are starting to look real and not plastic, but they are rendered offline by very fast processors.

- Nick Gammon

www.gammon.com.au, www.mushclient.com

Posted by

David Haley USA (3,881 posts)

bio Moderator

Date

Sat 10 Mar 2007 09:31 PM (UTC) [ quote ]

Message

Oh, you're entirely right; Oblivion requires a significantly more powerful computer to look right on. The computer I'm using now was built more or less specifically with Oblivion in mind. (Well, ok, not really; I also wanted it to be very fast for compiling and the like, and just fast in general.)

You're also right that the better something looks -- or rather the more it tries to be realistic --, the more demanding the viewer is. Oblivion suffers from this when it comes to dialog with NPCs, which is probably why you mentioned faces and moving mouths.

I think the big thing is that having a cartoon look and feel (or, really, any kind of stylized look and feel) puts the viewer into a different frame of mind, one more willing to accept slight problems (with respect to strict physical realism) because one is not looking for perfection to begin with.

David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org

Posted by

Nick Gammon Australia (18,800 posts)

bio Forum Administrator

Date

Sat 10 Mar 2007 09:16 PM (UTC) [ quote ]

Message

Quote:

WoW graphics are pretty good, yes, but Oblivion is even better ...

Yes, however with a couple of disclaimers.

First, I found that the exact PC and graphics card that rendered WoW fine, was very sluggish under Oblivion, and thus required an update. So, the better graphics came at a cost. If you didn't get the upgraded graphics card, it looked worse, because you had to degrade the drawing configuration.

Second, I find that the more photo-realistic the rendering is, the more you expect, and the more you notice things like sharp borders between (say) objects like players, and scenery, which should really be rendered with anti-aliasing to look perfect.

I also find that with very realistic rendering, you notice other things, like the face which looks like a photo with a moving mouth.

However, if the overall approach is a "cartoon feel", then you expect mouths and eyes to move in a "cartoon way", so they look better - if you see what I mean.

- Nick Gammon

www.gammon.com.au, www.mushclient.com

Posted by

Nick Gammon Australia (18,800 posts)

bio Forum Administrator

Date

Sat 10 Mar 2007 09:12 PM (UTC) [ quote ]

Message

Here is another example from WoW:

Note the slight shadow under the player, the light on the wall flickers and illuminates the wall, and you can see daylight coming in the door in the middle (with the guard walking past).

Also, the player's staff has a blue glow that shimmers and moves.

The yellow light on the top-left corner throws a yellow glow that brightens the scene near it, if you are close to it.

Probably the rendering is not mathematically exact, but it "feels right".

- Nick Gammon

www.gammon.com.au, www.mushclient.com

Posted by

David Haley USA (3,881 posts)

bio Moderator

Date

Sat 10 Mar 2007 09:11 PM (UTC) [ quote ]

Message

WoW graphics are pretty good, yes, but Oblivion is even better -- IMHO. :-)

Other good examples of very impressive (real-time) renders can be found at www.Ogre3d.org.

What it comes down to is that OpenGL can draw some very impressive scenes. Of course, things like light refraction/reflection are slower, but that's no fault of OpenGL per se, really, but the very nature of the computations needed to get that stuff right. (It's no secret why it takes ray-tracers so long to render scenes.)

I think atmospheres (like a yellow swamp feel) are typically rendered with some kind of overlay that is more opaque as distance from the camera grows. It's kind of like fog, although proper fog has some more complicated stuff behind it.

David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org

Posted by

Nick Gammon Australia (18,800 posts)

bio Forum Administrator

Date

Sat 10 Mar 2007 08:55 PM (UTC) [ quote ]

Message

If you look at World of Warcraft, it does an incredible job of rendering believable graphics in realtime. Take a look at this example:

This has been sampled down to save space, the original is better quality.

Notice the realistic-looking road, with trees that throw shadows. Interestingly the two characters on the screen do not throw sideways shadows (players and mobs have a small circular shadow under them at all times).

The light in the foreground (yellow flame) evidently uses a particle generator, because it flickers and moves all the time.

This is drawn in real time, about 40 to 60 frames per second, and you can change the point of view (camera) instantly by dragging with the mouse.

Many zones have an "atmosphere" which I think is just a coloured overlay (eg. yellow in a desert, green in a swamp).

They also have rain that, from memory, seems to splash as it hits the ground.

I get the strong impression it is a compromise between speed and photo realism - it really has a slight cartoony feel, but the important thing from the enjoyment point of view is that it is fast. Who wants really sluggish, but highly realistic, frames?

- Nick Gammon

www.gammon.com.au, www.mushclient.com

Posted by

Shaun Biggs USA (644 posts)

Date

Sat 10 Mar 2007 08:51 PM (UTC) [ quote ]

Message

how exactly is "L10=-100x0y20z#FFFFFF" a lot of data through a pipe? It takes care of the intensity "L10", position, "-100x0y20z" and the colour "#FFFFFF" in just a few bytes. Even before compression, that's less than the client saying "You have faint light coming from the mouth of the cave." This also takes care of the fact that you are not always facing in the same direction in each room, nor will the sunlight be visible from the same angle. In the cave example, the light is coming from the mouth of the cave regardless of the position of the sun in the sky.

It is much easier to fight for one's ideals than to live up to them.

Posted by

David Haley USA (3,881 posts)

bio Moderator

Date

Sat 10 Mar 2007 08:04 PM (UTC) [ quote ]

Message

Actually in several games rain and snow are treated with a particle engine. I'm not sure how exactly you are using the term "render", but the rain/snow particles are not slapped on at the end, rather, the particles are actually rendered based on their positions as specified by the particle engine.

Of course, other games -- ones that don't necessarily need rain that looks like it's in the scene, especially 2d isometric games -- choose to simply overlay rain as streaks drawn on top of the picture, usually with alpha blending of some kind. So you are right for some cases but your statement cannot be generalized to all rain rendering.

And actually, if you look at some really fancy rendering of rain in 3d art, it is also rendered using a particle engine of sorts, and not slapped on either; that kind of rain looks best because it actually glints with light and good stuff like that. It also varies in density on the screen depending on how "deep" you can see down a particular line; if you run into a tree you will have less rain, but if a line of sight goes on for a while there will be more rain visible. And again, the rain has depth, so this effect looks more or less realistic.

Quote:
the more stuff you have to send through the pipe. Its useful to avoid having to feed too much extra stuff through, if you don't have to.

I think you're worrying a bit too much about the data rate here. Specifying the sun's x, y and z angles only takes a few bytes. As long as the order of magnitude stays within the kilobytes instead of the tens, hundreds of kilobytes or megabytes, there is no problem.

David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org

Posted by

Shadowfyr USA (1,774 posts)

Date

Sat 10 Mar 2007 07:44 PM (UTC) [ quote ]

Message

See. The issue still becomes speed vs. realism then. Fog.. Is simple and can be done in the trace. Rain and snow, could too, but the methods really are little more than overlays, not true 3D. There is no light interactions, etc. At most, you *might* have 3D positioned "splashes" in the scene, but the rain doesn't do anything but just sit over the image and its not effectively different than making the far rain more transparent than the close, so it "seems" like the drops are bigger close up. Snow.. Is a tad different, but only in that its not going to fall in a linear path all the time or as fast and you need distinct flakes, not what basically amounts to streaks on the screen. Rain in a 3D card isn't rendered, its just slapped on as a layer effect, which is easy enough to manage and has been done since the days of the PSOne and simple isometric games (with fairly realistic effect).

As for having the client handle things like sun positions, etc. You could have more than one sun position, effects to alter how "bright" they are, etc. But its the render engine that needs to deal with it. The server end is figuring out certain details, but the more information you have to add, such as what "angle" the sun needs to be at, etc., the more stuff you have to send through the pipe. Its useful to avoid having to feed too much extra stuff through, if you don't have to.

main {
__if (Schrodinger_Cat is Alive or version >= "XP"){
____if version = "Vista" then Performance /= Number_of_Cores;
____call Functional_Code();}
__else
____call Crash_Windows();}

Posted by

David Haley USA (3,881 posts)

bio Moderator

Date

Sat 10 Mar 2007 08:54 AM (UTC) [ quote ]

Amended on Sat 10 Mar 2007 08:35 PM (UTC) by Nick Gammon

Message

Quote:
Adding rain or snow into the image after with OpenGL instead of just having the rederer do that would require one of those suboptimal hack jobs you were mentioning earlier.

PUtting aside the whole "can't make pretty pictures with OpenGL" and "can't procedurally specify for OpenGL" issues, it's worse than that. If all you're trying to do is add a simple overlay of snowflakes, or rain-drop lines, it would be silly to use OpenGL for that (you would get much better results using, say, the ImageMagick library). But if you want the weather to actually look right -- e.g., having fog in the scene due to the rain or snow -- you will need the original 3d data (in particular the depths) to even have a hope of having the render look right.

David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org

Posted by

Shaun Biggs USA (644 posts)

Date

Sat 10 Mar 2007 08:45 AM (UTC) [ quote ]

Amended on Sat 10 Mar 2007 08:50 AM (UTC) by Shaun Biggs

Message

Quote:
Basically, yes. But I would only save the "objects", so that something might include thing like:

using { "water\"
include "well.mob" as center_well}

sun_position { lat 50.045 time 14:43}

The first would pull in the script for a generic well, which you could then alter using:

object {center_well rotate <30,0,0>}.

ummm... that's exactly what I said earlier. Since you didn't notice, in the example I showed, it had sunlight coming through the opening, and the direction each item is facing. The time is also a weird idea for the client to deal with in regards to celestial bodies, since it would be easier for the server to just figure that out in order to deal better with different worlds. Some might have two or three suns or moons travelling at different speeds. Ambiant city light at different times would also be better server side. Those are things that can just be looked up in an array or hash table quite quickly.

Quote:
Since the point is to allow certain specific things, like lighting, to be dynamic, you need to be able to re-do the image as needed. Some things, like adding rain or snow, could be done with OpenGL, after the main image exists, since the effect would be overlayed onto the image, not animated. However, some tweaks to the surfaces (specifically their reflection, etc.) might be used to make everything look "wet".

Its not full animation, you can't rotate it to look at it from some other angle, etc. But you *will* notice, if you set it to allow it, that the light angles and shadows change over time as the sun moves, or similar stuff.

Adding rain or snow into the image after with OpenGL instead of just having the rederer do that would require one of those suboptimal hack jobs you were mentioning earlier.

Also once you start doing things like rotating an item, or moving the light source, you might as well just rerender the whole image, since that will change shadows and reflections on any decently populated room, and on slow computers, it can just re-request an update when it's done rendering (or after a 30 second delay if there is no change). Better updating would also allow for things like a ring of mushrooms appearing at midnight for an hour, or a door that disappears if the light is too bright to be dealt with easier. And with the compressed code, it wouldn't require much bandwidth at all.

And for everything after that point (since I'm not going to copy and paste the rest of the post, you are just repeating everything that I had said, aside from me forgetting to explain the "cave4" bit as being a full room with a height bitmap and a few standard terrain features that is stored by the client. Reusability is a key factor in making a program smaller and more efficient.

Also, beware of obscurement in anything you do... it's a double edged sword. Not only will you be protecting your data from people who want to crack it better, but you will make it much harder to read for when you or someone else has to go fix something.

Aside from tossing this into a script to pass the data over to yet another program, I'm still confused how this would be done in almost any client other than MUSHclient. It would be far simpler to just make your own client and have all of this embedded into it, especially if someone decides to move rooms before an image is fully rendered, and the client will have to figure out what to do with that unfinished process. The main advantage I can see about using a proprietary client instead of a mud client is that it would be easier to deal with adding unique items or doing updates, since it could download new patches at connection, or backgrounded throughout the runtime.

It is much easier to fight for one's ideals than to live up to them.

Posted by

David Haley USA (3,881 posts)

bio Moderator

Date

Sat 10 Mar 2007 05:28 AM (UTC) [ quote ]

Message

Quote:
Some things, like adding rain or snow, could be done with OpenGL, after the main image exists, since the effect would be overlayed onto the image, not animated.

OpenGL is not the most appropriate tool for adding pixels to an already rastered image. It's overkill and not what OpenGL is supposed to do. And besides, any technique will not be aware of the 3d contents of the scene, and so is likely to produce less than optimal results.

Seems to me that if you want rain or snow, you should just do it in your render.

Of course, since you seem really set on (at least quasi-)photo-realistic ray-tracing, you will have the problem of a slower and slower render...

David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org

The dates and times for posts above are shown in Universal Co-ordinated Time (UTC).

To show them in your local time you can join the forum, and then set the 'time correction' field in your profile to the number of hours difference between your location and UTC time.

11,520 views.

This is page 1, subject is 3 pages long: 1 2 3

Reply to this subject Start a new subject Refresh page

Go to topic: Search the forum

Comments to: Gammon Software support
Forum RSS feed ( http://www.gammon.com.au/rss/forum.xml )