Zone Creation Model/Texture issues

[OrisonSeven]

Ok, so our team has been hard at work for some time now comming up with some very detailed (often way too detailed for the game engine) meshes and textures all complied into a few zones we have been developing. There have however, like any undertaking, been some snags:
1. When using openzone/.s3d files, with 3dsmax texturing, are bump maps supported (for those who dont know bump maping, its like adding shadow texture to a flat texture to give the illusion of 3d) ?
2. When making trees and other foliage, the use of 2 sided planes (a plane with the same texture on both sides so as to keep polys low while creating leaves and realistic trees) doesnt seem to work. In other words, when rendering within max, the trees are correct, but while in game, only the primary side of the plane shows up, the secondary (back side that is typically black within max) is invisible. This results in 1 of 2 solutions both are very annoying and cause the poly count to increase. First, we have tried simply sticking 2 planes together ontop of one another, which doubles the poly count, and seems a bit excessive, and having them face opposite one another. This does fix the problem but doubles the polys which decreases preformance drastically. The second is to just use more planes all mangled together so that the clear sides arent really noticable (they actually really are). So, back to the simple question, Does openzone/.s3d support 2 sided polys, and if so, what could possible be the issue?
3. Is it possible to create an object but make it have no actual physical aspect to it, so that players can walk through it (i.e. fake walls, leaves and bushes that can be walked through, blades of grass, and so on.
4. We do wish to sue simple client because the use of animation/animated objects and things within the terrian would be huge. (some examples, static mesh with an animated texture for a waterfall with a particle/animation of spray where it pools, the ability to add some form of animated objects such as leaves falling from trees every so often, or zines swaying with the wind, to even the use as smoke from a fire).
5. We have a sound artist working to create alot of custom music for the game including overhalling some of the songs into new versions for a feeling of nastolga while traversing our lands. Can songs be used within certain parameters or zone wide and baked into the files so that we can with the use of a patcher, distribute them to people wishing to venture into our world?

We have had some success with ingame content, or rather importing and creating a zone as I will include a very and i will push the VERY, basic and raw version of a raid style zone that is reminiscient of Kelethen meaning there are tree top platforms, but rather then a city, it will be a massive arial maze of platforms that contain creatures that look like a merger of a goblin and an oversized gorrila called the Augrom. The idea will be for this to be for both small parties and raids becuase of the easier more open forrested area before getting to the elevated maze. We also are going to include alot more foalige as both barriers and to create the feeling of actual jungle. Also, alot of the textures are still in there first rendition or are acutally just textures that are thrown in simply to allow for a feel of the enviornment.

Images comming as soon as I recieve them from the tester.

[Tabidzukare]

Hi Orison,

I want to start by saying I thinks it's absolutely fantastic the things your team is doing and I wish you the best of luck in your project. A good team is hard to compose and it sounds like you've done great with that!

I don't know if this is an actual answer, but as far as the invisible wall / trick wall thing. Though I have little experience with OZ, I believe you have to physically define the zone bounds. If you just create a flat panel of texture that doesn't have those properties in OZ I think you could create this effect.

That's a bit vague but if you've just got a panel of texture that isn't defined as blocking movement it will achieve the desired effect. You'd just have to leave a gap in whatever meshes you were importing into OZ and make the panels from within OZ itself.

Also, check Steve's thread, I posted a response that maybe enable me to help you further.

Kindest Regards~~

[OrisonSeven]

I understand what you are saying, and yes it helps, but the most important thing for us right now is the trees as if we have to double the poly count, we will have to decrease the rest of the polys and thats not the best idea as we want the zones to look good.

I have done some massizve searching across the boards and found some helpful info, but alot of the links on some of the pages no longer work including the tree creation tutorials and the PDF files to explain.

Any help woule be greatly appreciated.

[OrisonSeven]

So, as promised, here are a few basic screens of a massive forrest zone under creation which has been named Ferringor. Within the forrest will be both areas for PuG groups as well as for more raid style play where team interaction and cooperation will be essential for even the entrace to the "dungeon" portion of the zone, though it is outdoors. In order to stop people from just levitating and skipping the lesser stuff to farm the end zone mobs, there will be hanging vegitation that will act as barriers without the necesity for invisable walls.

http://i265.photobucket.com/albums/ii230/Icedfate/Ferringor/EQ000003.jpg

http://i265.photobucket.com/albums/ii230/Icedfate/Ferringor/EQ000002.jpg

http://i265.photobucket.com/albums/ii230/Icedfate/Ferringor/EQ000004.jpg

http://i265.photobucket.com/albums/ii230/Icedfate/Ferringor/EQ000000.jpg

[OrisonSeven]

I decided that all in one night that updating what we have would be fun. Here are some new screens from ingame of Ferringor. No mobs or "trash" objects as of yet, but still trying to get the terrain to look quite perty. Also, u may notice things look alot bigger then last time. We had the zone scaled down a lot but are now bringing it up to size.

http://i265.photobucket.com/albums/ii230/Icedfate/Ferringor/EQ000005.jpg

http://i265.photobucket.com/albums/ii230/Icedfate/Ferringor/EQ000006.jpg

http://i265.photobucket.com/albums/ii230/Icedfate/Ferringor/EQ000009.jpg

http://i265.photobucket.com/albums/ii230/Icedfate/Ferringor/EQ000010.jpg

Any comments, pointers, remarks, or any other kind of input is always accepted.

Thanks to all at eqemu for makin this possible!

[Tabidzukare]

Hi Orison,

I see your idea more clearly now and I have some ideas along. Again these are just conjecture as I have no real experience with what you're trying to do, just offering my thoughts.

In my head If you are trying to limit players ground based movement through thicker parts of the woods, you could just use zone borders creatively by having them outline your 'progression' through your zone. I wish I had a clear concise way to explain this, unfortunately I don't, so here's my best attempt.

Traditionally zones have a 'wall' or a portion of visually high altitude area that clearly blocks player movement and this is supported in OZ by the zone boundaries. If you are trying to direct players progression through your zone to given areas, or forcing them to traverse through certain challenges to get to other regions in the zone you could accomplish this by 'sculpting' your zone boundaries to match the 'map' of the areas and their flow. Rather than having a big clunky zone wall show the players where their limits are, it sounds like you want give them a more subtle environmental cue to them as to where they can't go.. If you outline via thicker tree covers / graphical contexts where 'areas' in the zone are and support these visual cues with a zone wall you'll effectively have an 'open looking' zone while still directing player characters movements. This will prevent players from effectively 'levitating' to newer areas directly because the zone borders extend upwards farther than traditional EQ spells would allow them to traverse unless they blasted themselves up with lev on, even then they'd still have to follow the zone lines just they'd be able to avoid mobs assuming they could blast themselves high enough. To limit vertical movement (again I don't know for sure if this is possible, but from going through only the basic tutorial it might be..) try creating a horizontal plane that either has a clear texture or is not visible that doesn't permit actors to pass through it.

I have some other ideas as well how you could engineer this idea, however until I understand more your desired implementation it might be fruitless to post them :)

Kindest Regards~~

[OrisonSeven]

Basically, we do not wish to have the "invisable wall" notion anywhere within the zone beyond the outer zone bounds that should have terrain blocking the path to begin with. So, on that not, we still want to control the flow of players as they pass through the "open" tree top dungeon. By using planes with a foliage texture, we are going to attempt to sculpt the feel of the dungeon aspect. One thing we want to keep and actually utilize is the fact that it is open, and therefore, casters with "knockback" nukes will be able to effectively cause massive havok to a party that is unaware of this, or that are not ready to combat such spells.

So, back to the ideas, yes using invisable planes would prevent passage, and we could also use one as a "ceiling" to limit verticle travel, which the ceiling may infact be utilized, more so is the importance of a realistic feel of being able to enjoy the freedom of not being stuck down in a deep hold or between some bricks of a castle wall.

Another idea currently under consideration is keeping the area completely open, but making it so that levitate is actually required. In other words, we would be removing all bridges beyone the first one, and therefore would have to figure out a way to limit "bypassing" of portions simply by limiting verticle initial height so that as u slowly decend while using levitate, u can only get to the next tree. This would also lead to some interesting tactics for goups to attack areas as we could make the final raid area lower then the previous one so that the group could decend upon it after strategising on the platforms prior.

But these are just some ideas. Also, the size of the zone is still limited and will be drastically larger once done. One of our key thoughts while working on this project is to remove the "zoning" then run to the dungeon, "zoning" then run to the deeper dungeon, "zoning" now run to the deep raid part, "zoning" and now fight like hell to get to the raid bosses. Rather we want to have huge expansive zones that could be traveled for an hour (prehaps a bit large right now" and no zoning needed while running continuously. This means running at accelerated speed (bard speed, SoW, and so on).

Larger zones also bring up the issue with computer load times and so for that reason making a huge piece of eyecandy means both drastically higher poly count then previously seen in eq as well as potential decreases to proformance on the users end if the zone is too "dense".

We played with high poly trees, and by high poly, i a referencing with respect to the current trees (high poly have about 2400 for just the leaves, low poly are around 20) and the trunk of the tree is also drastically reduced (from about 300 to closer to 50). This is all done so that when having about 800 trees, plus the 100 or more (eventually close to 400 I suspect) and the terrain will be closer to 4000, that the poly count would be astronomical. Just the leaves alone (actually i need to double 2400 to 4800 becuase right now 2 sided polys dont seem to show both sides, so they have to be doubled and then the normals have to be inverted) would be 4800 *800 for the current size which since max has a face export limit of 64k, would mean 3,840,000 polys for leaves... and then break that down by 64k blocks, rounding up to 3.9mil for the few extra trees and such would be 3.9mil / 64k = ~61 seperate pieces for just leaves. This is where both max and the creation of zones is hurt as if u look at our older images posted, the trees there were inface much more realistic and were many times more complex.

So, all in all, we have found what does work, and what doesnt for the most part. There are still some things we are working to fine tune, but we hav amassed a huge collection of object that will be added soon as well.

--Any idea if bump mapping works? as this would change the feel of the game drastically,

Thanks for all the support, help, and advice/information.

[OrisonSeven]

Here are some new updated screens:

http://i265.photobucket.com/albums/ii230/Icedfate/Ferringor/EQ000011.jpg

http://i265.photobucket.com/albums/ii230/Icedfate/Ferringor/EQ000012.jpg

Zone is getting alot larger.

[OrisonSeven]

Figured its time to update, though the actual zone images will not be up for a few more days. Our team has been hard at work, and I also just upgraded my system from an old turtle to a new beast.
New system specs are:
Intel Core I7 920 @ 2.66 ghz (before overclocking)
6 gigs PC2000 OCZ triple channel ram
radeon 4870 with 1gig GDDR5 ram

the rest of the parts are nothing really special, though this compaired to an AMD 64 2800 with 2 gigs ram and an AGP based video card makes a world of difference.

The only down fall is that with so much more processing power, the zone detail has shot through the roof, and therefore is going to require a computer a bit more powerful then some may realize. That being said, the first full zone is well on its way.

Mobs are also being sketched and designed along with custom animations, and a slew of features we hope to impliment along with a patcher so that people can patch to our build while they are logging in.

We also just got a hold of a coder who has some promising ideas that are being coded, tested, and so on. Our QA group is also hard at work trying to fix any bugs they come across.

Photos to come soon

[Tabidzukare]

Hey Orison,

Glad to hear an update! Myself, I've been cracking away at learning that ever elusive 'C++' language :). It's pretty difficult for me personally, but how can one not be motivated to study it when they have all the old source for EQEmu at their fingertips. Slowly but surely I'm being able to pick apart some of what lies in their murky depths! Secondly I've gotten a pre-calc book to start buffing up for calculus for the long haul to openGL math so I can one day .. (scowls) be able to make the proper changes or my own tool for extracting all the visual assets of EQ... That day will come as will your project, but it's all about the time it takes.

Happy hunting friend and here's to dinging 60 IRL!!

Kindest Regards~~~