Guild of Writers

I needed to get all my "notes to self" about age building organized and decided I may as well start a thread here and share my little tidbits of knowledge. Besides, this way maybe someone else will share too .

- Increment. Every single time something is added and I get it right, increment the age. Sooner or later, I'm going to make a big mistake and not discover it till it's too large to correct. Incrementation will save my butt when that happens.

- Don't get too ambitious when a "great" new idea comes to my mind. It's much better and faster to try a new texture idea out on a cube or a sphere in a test age than to build a great big landscape and then discover the texture I wanted to use looks awful in the actual game.

- Perfect lighting is directly dependent on perfect geometry. Don't blast out a quick messy model and expect the lighting to make it all better. It won't work.

- It's better to build something simple and build it really well than to attempt to build the most fantastic, awesome, never-before-seen age and mess the whole thing up.

- Other people actually do know things that I don't. When in doubt, ask.

Constructive Criticism: don't be afraid to ask "how can I make my age good enough for the open source version of Uru,"
and don't be overly concerned about telling someone "its not good enough because of X,Y, and Z" if their asking for your advise.
The programmers may not have time to go threw your age and tell you specifically what it needs to be "up to par"
but keep in mind the language and understanding of programmers may be a bit different then that of 2D and 3D artist.

Artist come in all shapes and sizes and some can't be bothered jumping threw all the hoops required by Open Source and understandably so,
the older game engine like the DI shard does allows more creative freedom and is less restrictive.
and /jump 100 don't work on open source

Edit to Correct

- Avoid absolute colors. Absolute white, black, red, orange, etc. Toning the color tones down will almost always improve the final in-game appearance.

- Blend. There are no sharp edges in nature. If it's an exterior scene, blend, blend, blend. It will look 1000% better.

- Never think anything is done until a real artist has a chance to look at it. My strength is my technical skills, not art.

- Images are best saved as .png files and need to be squared (64 x 64, 128 x 128, 256 x 256, etc) or rectangles (64 x 128, 64 x 256, 128 x 256, 512 x 1024, etc).

- Standard pixels per inch is 72. A higher ppi is equivalent to a larger image in the texture.prp file. Always remove the alpha layer from images if it isn't needed.

- pyPRP will only export up to 10,000 faces in any single object.

- build simple colliders around complex meshes. All colliders should be volumetric (i.e. not planes).

19.8.13 - Edited to strike out ppi resolution comment (Thank you Tach ) - image ppi resolution can be ignored for our purposes, it's only relevant to printing on paper, not screens. Corrected and sorry!

Calena wrote:- pyPRP will only export up to 10,000 faces in any single object.

The "limit" is 65,535 (better known as 0xFFFF to programmers) 32,768 (or 0x800 to programmers) vertices per mesh. If you're exceeding this, it's a clue that you'll probably want to rethink something

fixed mistake as pointed out by tach

Tsar Hoikas wrote:The "limit" is 65,535 (better known as 0xFFFF to programmers) vertices per mesh.

Umm... I'm sorry I must say this, Adam, but this does not reflect reality.
Of course, this 65535 limit is the case in my own PyPRP1 adaption, and I would really appreciate it if this was the case in the official version as well, but the recommendation I made in this post: viewtopic.php?p=52159#p52159 did not make it into the official 1.61 version.
So the vertex limit is currently still 0x8000 = 32768 verticies.

(By the way, technically this hex 8000 limit = 32768 has no direct relation to the BufferGroup limit which is 32000; and even IF it had, 0x8000 would be a definitely wrong value. 32768 != 32000, obviously. What internally happens is that if a mesh has more than the BufferGoup limit (>32000), it's automatically splitted into multiple BufferGroups, which is totally okay and desired behavior. So I would again recommend to increase the vertex limit to 65535.)

I tried producing a Halloween Relto page with a skeleton I found on the net that had 37941 vertices and 75397 faces but it would not export
I dont think it would have fit in the wardrobe any how

Karkadann wrote:I tried producing a Halloween Relto page with a skeleton I found on the net that had 37941 vertices and 75397 faces but it would not export
I dont think it would have fit in the wardrobe any how

LOL! I did the same thing. I found a gorgeous pine tree model complete with snow online. I downloaded it and opened it up in Max2011, then checked the poly count. 800,000+!!! I tried, I really tried hard to optimize that model to bring the face count down to something workable. I finally had to give up.

Note: The newer versions of 3dsMax have a really nifty tree/plant feature that makes creating our own tree models with a reasonable face-count fairly simple. If anyone needs nice low-poly trees, I can provide .

tachzusamm wrote:...So the vertex limit is currently still 0x8000 = 32768 verticies.

Ok, so in other words; 16 bit signed and rounded down to 32000, for whatever reason (reserved range? safety buffer?), divided by three (...non shared vertices per face) = 10666 tris?

No! This 32000 BufferGroup size is NOT a limit for the mesh! Don't confuse this. This 32000 value only determines the boundaries where the mesh is splitted and another BufferGroup will be begun.

Example: Assume we have two meshes, one with 20000 verticies, a second with 16000 verticies. The first mesh fits completely in one BufferGroup, but it can hold 12000 verticies of the second mesh as well (20000 + 12000 = 32000). Then a next BufferGroup will be allocated, holding the remaining 4000 verticies of the second mesh.

No need to force putting a mesh completely into one BufferGroup.

Don't worry about buffer groups, they're an implementation detail.

Yes, you're right. I forgot that indices are signed shorts. Whoops We really should bump the limit (as you suggest). The engine is unmanaged code, so only the compiler cares about the difference between signed and unsigned shorts. The best way to get that done is via a pull request or by opening an issue on github. It's easy to forget things that are spread out over them forums