Ryzom

wangxuan2730,

When you're building an instance group for a building with an interior (even if the interior doesn't teleport you to the indoors continent and into a cell/instance) you need to place a PACS primitive in front of the door. How this is actually placed is a tiny bit convoluted. Take the file w:\database\stuff\zorai\decors\constructions\salle_npc\zo_bt_piece_npc.max. If you open this file you'll find a a dummy object called zo_asc_dummy01. If you click on it and open the Tools tab and choose "Node Properties" from under NeL Export then switch to the Instance tab you'll see it has an "Instance Shape Name" defined as zo_asc_2portes.pacs_prim. The system, server and client, when seeing this dummy object will inspect its instance shape name settings and upon seeing a pacs_prim it will relocate the PACS primitive object to the location of the dummy.

To get details about the PACS primitive object you will next need to open zo_asc_2portes.max which is oddly located in w:\database\stuff\jungle\decors\zo_asc_2portes.max. When you have a PACS primitive in a MAX file the build_pipeline will automatically export it to the name of the MAX file. So upon opening this file you will see that the PACS primitive object in the scene named "PACS Box01" - this is because the name of the box is totally irrelevant. Select it and switch to the modifiers tab. You'll see here there's a PACS rollout with User Data fields. These determine the pacs_trigger_id and other collision data of the object. You can tie these pacs_trigger_id to things like teleport triggers in World Editor. It also has data about what type of door to use. So if you open another file from the same folder such as ma_asc_village_a_bar_ext_1.max you will see similar settings. The difference is that "User Data 0" in the zo_asc_2portes is a value of 2 and a value of 1. A "User Data 0" of 1 means "ascensor" and is typically used as a teleport trigger. A "User Data 0" of 2 is a door and triggers the client door manager code.

Now for a bit of disappointing code. If you open code/ryzom/client/src/door_manager.cpp and head on down to line 324 you'll see the beginning of the code that loads the door shape and animation. At 324 you will see something like this:

1                        if (strnicmp(pDoor->Name.c_str(),"ma_asc_3portes_bourgeons",24)==0)
2                        {
3                                pDoor->AnimType = SDoor::Matis3PartBourgeon;
4                                pDoor->Instances.resize(3, 0xFFFFFFFF);
5                        }

It is actually keying on the name of the PACS primitive - in our example it is looking at zo_asc_2portes to make a determination about the shapes to load.

Hope this helps get you started.

Yes, now I can start,thank you .

sfb!!!

I have another problem, in the max file, the "Node Properties", what's the difference among "instance shape" , "instance name", "instance group name", I know the meaning of the tab name.

But I don't know how to set it....

wangxuan2730,

First just to make sure every one knows what an Instance Group is. In terms of Ryzom Core an Instance Group is kind of a scene of sorts. It is a collection of references to shapes, effects and lights with coordinate data relative to each other. The instance groups contain records of instances and not of actual shapes so that when it loads it will seek out the actual shapes from the shape bank or file system and load them into their correct positions. It helps reduce duplicate game data since many props are used frequently.

So to define your terms:

• Instance Group Name - this is the overall name of the instance group. You set this to be the same on all objects in the scene in MAX which you want to be part of the instance group.
• Instance Shape Name - this is a reference to the name of the shape the instance represents. Upon loading an instance group the client (or server in some rare cases) will extract this value and then load that shape into place. Note - this is very important - this value is automatically generated upon export using the name of the object in MAX. You should only set this value if you have a very particular need! For example placing PACS collision objects (pacs_prim). This field is typically used to forcibly transform a dummy object. This is not very common.
• Instance Name - this is a reference value used for instance group tranform callbacks. Within the Instance Group system you can create a version of the ITransformName class that intercepts the startAddingIG stage of the pipeline and, as the name suggests, transform the name of the shape being loaded. Since the client code implements this functionality through an implementation of the "transformName" method the use of Instance Name is dependent on a case-by-case basis and thus is either completely ignored or used for specific situations.

Lets look at the door as an example of a real world application for this. The MAX file for zo_bt_piece_npc defines the instance group name which is essentially just the name of the file that the instance group is saved to (e.g. zo_bt_piece_npc.ig). In the code for the client you will note that CDoorManager is an implementation of ITransformName and you can see the two main functions called are transformName and loadedCallback. In transformName we make sure that the instance shape name (see above) is a pacs_prim and then block loading of a mesh for the instance group. In the case of the door we set the instance shape name to zo_asc_2portes.pacs_prim. The door manager will then bypass loading the mesh for the door then during loading it will retrieve the Instance Name and use it to make a determination about what kind of door to load.

Another common case for this parameter to be used in for loading plants (trees and not micro-vegetation.) If you open a plant scene you'll see typically four objects in the scene. Two levels of LOD mesh (normal polygonal count and a billboard), a dummy used for normal and a PACS collision object (usually a cylinder the diameter of the trunk.) Nothing overly special is set in Node Properties except for the smoothing group for radial normals and the LODs. But trees are placed using World Editor and when you these 'prim' primitives on the map a tool called prim_export actually processes them. Now you wouldn't typically place a 'prim' class manually - you'd place a flora using a flora_template and then generate the primitives for the trees (the template specifies things like denisity and jitter to automatically place trees.) Not to get too into the details of how trees work but the prim_export tool sets Instance Name to the name of the .plant sheet. The CIGCallback class is going to grab the plant sheet name and do some magic using this sheet. The plant sheet, you see, contains information about how to affect the plants based on the season (specifically used here is the SpringFX, SummerFX, AutomnFX and WinterFX structs which define particle systems to load based on season.)

I'm not aware of very many places that use these optional parameters (Instance Shape Name and Instance Name).

Hope this information dump helps you out!

Thanks,
sfb
/s

Yes ,maybe I know, another question is that,the door can animate, but how does it animate, there is no animation file.

wangxuan2730,

I can't really explain here what it is doing since I'm not much of a 3D guy but suffice to say that the magic happens in door_manager.cpp in the client source in a method called:

1void CDoorManager::SDoor::anim()

Check it out. It appears to manipulate the material by moving it's position so that it disappears. Doors in Ryzom tend to slide out of sight rather than pivot open.

Thanks,
sfb
/s

Yes, I guess so, thank you , I'm thinking about how to control the animation...