Question to Xavier Antoviaque : my idea for Ryzom 2.0

An archived topic, merged from 4 captures made between 31 October 2007 and 7 November 2007. ryzom.org · Forum index · All captures

Author

Message

< Ryzom.org General - English ~ Question to Xavier Antoviaque : my idea for Ryzom 2.0

Browser_ice

Posted: Thu Oct 11, 2007 8:06 pm

Joined: 08 Oct 2007 Posts: 5

Today, while brainstorming, I had an idea that led to a question for Xavier Antoviaque.

In your current plans for Ryzom as stated in your forum, do you have the intention to keep using the same graphic engine ? I am prety sure this is the case because why look for something else when you have something that is already working.

But, because of its current concept limitations that do not allow a true 3d environement, to re-write it would be a tremendous task. So this is where my idea comes from :

Why not license an existing graphic engine that is truely 3d ? The first engine that comes to my mind for this is "Ennemy Territory: Quake wars". This engine is already proving its possibility as a 3d engine for outdoors gameplay while using materials that have bumpmaping, normals and specular. I strongly believe that this engine would be ideal for Ryzom 2.0 or even 1.0 (althought I do not believe it will be the case).

What do you think ?

Who knows, maybe the community is ready to participate in its financement ?

_________________
Browser_ice

http://browser-ice.deviantart.com/gallery/

Xavier Antoviaque

Posted: Thu Oct 11, 2007 10:33 pm

Joined: 15 Nov 2006 Posts: 390

Browser_ice wrote:

Why not license an existing graphic engine that is truely 3d ? The first engine that comes to my mind for this is "Ennemy Territory: Quake wars". This engine is already proving its possibility as a 3d engine for outdoors gameplay while using materials that have bumpmaping, normals and specular. I strongly believe that this engine would be ideal for Ryzom 2.0 or even 1.0 (althought I do not believe it will be the case).

What do you think ?

While it is a nice idea to think about improving the graphics engine, it is also an incredibly difficult task. It would probably need a complete rewrite of a significant part of the codebase. And there is also the issue of using a Free Software engine, which narrows the choice quite a bit.

Once (and if) we get the code, you'll be able to start a debate on this, try to build a team and get the approval of the community, but my bet is it will be too difficult to be done.

_________________
Xavier.

Kaetemi

Posted: Thu Oct 11, 2007 11:46 pm

Joined: 24 Nov 2006 Posts: 31 Location: Lembeek, Belgium

Browser_ice wrote:

limitations that do not allow a true 3d environement

Uh, you have X, Y, and Z, what more do you need for 3d? ^^

_________________

Edward

Posted: Fri Oct 12, 2007 5:17 am

Joined: 15 Jan 2007 Posts: 31

It should be possible to use another engine (such as the ones discussed in this thread) with Ryzom. Anyone so inclined could experiment with running Ryzom on another open source engine (though of course they couldn't use the Ryzom name without permission).

dentom

Posted: Fri Oct 12, 2007 4:06 pm

Joined: 05 Oct 2007 Posts: 9

I think a new graphic enginge won't habe the approval of the community. The graphics, especially the "warmth" of the world which is mainly driven by the graphics is what defines a big part of the fascination of Ryzom. I play regularly other MMOs and even high-end MMOs like Vanguard with its detailed Textures and Models does not have the same immersion and warmth like Ryzom.
I never heard of complaints about the graphics of Ryzom - in the contrary. But I heard complains about missing content and promised game features like guild trainers, interactions with tribes, rites and the kitin lair.
So why investing time in changing something the majority of players is very content with?

_________________
Chanchey Breggan
on Leanon since Feb 05

Cayle

Posted: Fri Oct 12, 2007 4:20 pm

Joined: 20 Dec 2006 Posts: 79 Location: Germany

This thread is about what can be done in the event that Ryzom is unavailable. If Ryzom can be bought, then changing the graphics and engine is not needed.

_________________
The Ruleset Modeling Language - A project for making it easier to design virtual worlds.

dentom

Posted: Sat Oct 13, 2007 4:46 pm

Joined: 05 Oct 2007 Posts: 9

But if Ryzom is unavailable, you simply won't have the rights to call it "Ryzom II", because you don't have the access to the lore, the name or the player-base.

So if it doesn't have to do something with ryzom at all in the end...? :)

_________________
Chanchey Breggan
on Leanon since Feb 05

recentcoin

Posted: Sat Oct 13, 2007 6:05 pm

Joined: 15 Jan 2007 Posts: 55

This is just another point in my argument for Xavier running a pledge drive to hire coders to build out Delta3D for gaming.

It doesn't need *that* much work and its got all the features you're asking for.

_________________
TIA,

RecentCoin
Epoch The Game
www.magnaturris.com
Project Angela
www.rpg-gamerz.com

soloreaper

Posted: Mon Oct 15, 2007 12:31 am

Joined: 03 Oct 2007 Posts: 7

Kaetemi wrote:

Browser_ice wrote:

limitations that do not allow a true 3d environement

Uh, you have X, Y, and Z, what more do you need for 3d? ^^

you have lots of X, Y on top of each other, there is no true Z, hence being able to heal someone from a cliff.

Kaetemi

Posted: Mon Oct 15, 2007 1:22 am

Joined: 24 Nov 2006 Posts: 31 Location: Lembeek, Belgium

soloreaper wrote:

you have lots of X, Y on top of each other, there is no true Z, hence being able to heal someone from a cliff.

There is a Z. All entities have a Z position. It's just that the action system doesn't use Z in it's calculations for distance...

_________________

Kervala

Posted: Mon Oct 15, 2007 8:57 am

Joined: 24 Nov 2006 Posts: 210

Kaetemi wrote:

There is a Z. All entities have a Z position. It's just that the action system doesn't use Z in it's calculations for distance...

I confirm :p

_________________
Cédric OCHS / Kervala / Xiombarg

Zero_tacg

Posted: Mon Oct 15, 2007 10:44 am

Joined: 27 Nov 2006 Posts: 17

you have to seperate the graphic (engine) and the "game" engine
the graphic in ryzom is fully 3d otherwise you'd have sprites walking around or something.
changeing the graphic engine wouldn't really change the look it would just sub/add some featrures/shaders support or what ever (for graphic engine ogre would be a good choice ;D, not sure but I think someone already succeeded in using ogre with nel), not sure how well it would integrate in the d3d/opengl driver coded by nevrax, which seem to do the fluid detail changes etc, which other graphic engines might not have implemented.

to the 2D movement ingame, ryzom uses b-splines or what ever, curves so the landscape can be calculated in realtime and detaillevel can be changed in realtime. Players etc are just snapped to ground since they'd fly in the air for a low detaillevel or in the ground.

I admit though jumping around from the faterfalls diving in tryker surely would be nice features ;)

recentcoin

Posted: Mon Oct 15, 2007 10:38 pm

Joined: 15 Jan 2007 Posts: 55

Unless the game engine itself is 3d, and not all of them are, you can render 3D-esque stuff by fudging the Z axis.

Other game engines really are 3D which means you can do stuff like have procedural terrain. What that means to you and what Ryzom likely can't do, is that you can't dig a ditch in Ryzom. Whereas if you are laying siege to a castle in Delta3D, you can send in the sappers and they can start trying to tunnel under the walls. You can dig wells, mine for ore, etc.

_________________
TIA,

RecentCoin
Epoch The Game
www.magnaturris.com
Project Angela
www.rpg-gamerz.com

sfb

Posted: Tue Oct 16, 2007 2:14 pm

Joined: 28 Nov 2006 Posts: 46 Location: Minnesota, USA

recentcoin wrote:

Unless the game engine itself is 3d, and not all of them are, you can render 3D-esque stuff by fudging the Z axis.

The "NeL is 2D" argument is a common misconception. NLPACS was made to do simple collisions in 2D. There are certainly limitations to this but even Nevrax admitted that PACS was... substandard. Eventually they stopped using it for everything except landscape management (snapping characters to the terrain.)

recentcoin wrote:

Other game engines really are 3D which means you can do stuff like have procedural terrain. What that means to you and what Ryzom likely can't do, is that you can't dig a ditch in Ryzom. Whereas if you are laying siege to a castle in Delta3D, you can send in the sappers and they can start trying to tunnel under the walls. You can dig wells, mine for ore, etc.

Procedural terrain is a fantastic idea in theory and has some very fun implications in practice but what it allows you to do in flexibility (your example) you lose in practical performance. There can be an argument made both ways. The Nevrax devs saw concrete terrain management as a challenge that they could solve several ways - procedurally or through tools.

They chose the tools route - they developed a system that we in the community call Ligoscape (I'm not sure what it is called internally.) It's called Ligoscape for two reasons - the driving library is called NLLIGO and what is left of a plugin to generate it is called Ligoscape. The summary of Ligo is "legos for landscape." In otherwords you can take 2D tiles representing landscape terrain types and lay them out and then drill down into them. I think this really compensates for the stresses of having to create a massive world of terrain.

The other argument for a NeL style-terrain system is two fold but comes down to a single item: performance. NeL uses bezier patches to produce terrain which allows for some fantastic terrain (overhangs, sheer drops, tunnels, undulation, etc.) But bezier patches are very expensive, so they must be pre-generated (the zone/zonel files.) On the flip side I have also work with procedural engines such as Mercator. Mercator allowed some really awesome dynamic interaction but failed in one critical aspect - at its heart it was a 1D (heightmap) landscape engine. Nearly all procedural landscape engines are this way. So it's a trade off - what do you want? Fantastic looking artist friendly landscape or uber-dynamic, uber-customizable user-interactable landscape? It all depends on your game play and it is a decision that has to be made.

Cayle

Posted: Tue Oct 16, 2007 3:15 pm

Joined: 20 Dec 2006 Posts: 79 Location: Germany

A couple of practical questions:

Some of the more modern terrain systems are heightmapped based. is this lego system more of a heightmap style where the legos form the basis of a heightmal, or a true tileset system, such as in the original Neverwinter Nights?

What kind of artist workflow does it have? Heightmapped systems have a huge advantage in being able to be generated or imported from SRTM data. For example, the Torque Atlas and Multiverse workflows usually start in L3DT or some other terrain creation program and then export everything, heightmap + texturemap to the game engine. True tileset systems usually require 100% manual placement.

How big are zones in NeL? I assume that is is zoned.

How is collision detection done now?

_________________
The Ruleset Modeling Language - A project for making it easier to design virtual worlds.

sfb

Posted: Tue Oct 16, 2007 4:39 pm

Joined: 28 Nov 2006 Posts: 45 Location: Minnesota, USA

A couple of practical questions:

Cayle wrote:

Some of the more modern terrain systems are heightmapped based. is this lego system more of a heightmap style where the legos form the basis of a heightmal, or a true tileset system, such as in the original Neverwinter Nights?

Nothing in NeL is heightmap based. The best way to understand Ligo is probably to just look at the NelLigo documentation. It allows artists to visualize large chunks of landscape from a birds-eye-view in 2D but the actual data is built from 3D geometry with transitional 3D geometry. The end result is a full 3D set of landscape generated using bezier patches. The "tile" view of landscape is nothing more than a visualization tool.

Cayle wrote:

What kind of artist workflow does it have? Heightmapped systems have a huge advantage in being able to be generated or imported from SRTM data.

Unfortunately there are no Free/Open tools for ligo right now. So there isn't any artist workflow. My hope is that the tools will be opened when and if Ryzom is opened. If you look at my previous link you can see some examples of artists working on landscapes.

One thing that is important to note is that there is a MAXScript for NeL that allows you to generate zones from heightmap data. This is a powerful way to quickly generate a zone and then modify the bezier patch so you can harness the workflow of generating landscape from 1D textures but still maintain the flexibility of working with bezier patches.

Cayle wrote:

For example, the Torque Atlas and Multiverse workflows usually start in L3DT or some other terrain creation program and then export everything, heightmap + texturemap to the game engine. True tileset systems usually require 100% manual placement.

Ignoring ligoscape - with NeL you set up your zones (which is an ambiguous term when you're a NeL developer and artist) in 3DSMAX and export them into the media pipeline. This pipeline converts the landscape into a NeL-usable format and sets up the data for the dynamic LODing (which works fantastic in NeL) as well as performing all of the nice things such as "burning" shadows for instance groups (instance groups are a NeL concept that basically mean static, non-movable objects that will always be loaded into the terrain.) These are all meant to boost the performance of landscape rendering.

Cayle wrote:

How big are zones in NeL? I assume that is is zoned.

Like I said before, this is an ambiguous term in NeL. A NeL zone is 160x160 meters (1:1 ratio for MAX units.) But a "zone" in NeL is a small segment of the overall world (zones are loaded dynamically based on a specified threshold and your viewable distance.) What you, as a player, perceive as a zone is actually a collection of NeL zones. That being said - NeL theoretically supports 65536 zones at 160x160 meters each.

Cayle wrote:

How is collision detection done now?

I can't speak for Ryzom specifically but in the community we're mixed on how we do collision. One project, for example, uses ODE. But that works fine for him since he doesn't use any of the landscape code (and thus none of the collision chains, etc.) There have been attempts to do ODE collision with NeL landscape and most of them fall short but I think it's more for lack of time and ambition than for lack of ability to actually accomplish this. I personally am using PACS right now. One of the things on the docket for NeL (as an open-source project) is to further PACS into a new, better lib. But this isn't going to be done by me (I don't have the expertise and the time) so it will have to wait until we have someone willing and capable.

For the most part the 2D-nature of collisions in PACS doesn't really create that large of a problem if you keep that in mind. The issues that have been mentioned here are actually not related to PACS - most of the time this is a dev trying to save space on a message transmitted to clients by using a 2D vector instead of a 3D one - or something along those lines. The biggest challenge that PACS has provided for us has been in the "bridges" situation. A situation where you have a bridge with a collision mesh but a walking path below it. Nevrax worked around this issue and was kind enough to share their workaround with us.