Anyone interested in client development? - Page 10

ableard · #**136** 03-26-2012, 04:54 PM

PuxelEngineer, I did see the zone.renderWholeZone. But when I used that not everything was displayed. I thouhgt it ws unfinished.

If you pull up qey2hh1, run up and look east. You do not see the entire zone, down by the river is not complete, no river, no river bank, there are patches out in the distance that are open. Some of the edge hills are not displayed.

PixelEngineer · #**137** 03-26-2012, 08:19 PM

Quote:

Originally Posted by ableard

PuxelEngineer, I did see the zone.renderWholeZone. But when I used that not everything was displayed. I thouhgt it ws unfinished.

If you pull up qey2hh1, run up and look east. You do not see the entire zone, down by the river is not complete, no river, no river bank, there are patches out in the distance that are open. Some of the edge hills are not displayed.

I will check that zone when I am home. In the meantime, I'd like to see your changes to the 0x22 fragmentfunction. Again, the idea isn't to add all of the regions to the PVS. The PVS is super useful as a first pass method of reducing the number of regions to consider for rendering. But if you are just rendering with renderWholeZone, and still see missing regions, chances are there is a bug and I seem to remember a region missing when exploring Sleeper's Tomb and just assuming it was the location for an object or something silimilar. Thank you Ableard.

Post the changes on pastebin or something and send me a link if you would.

Cheers!

PixelEngineer · #**138** 03-27-2012, 09:45 PM

Thank you for noticing this bug. Turns out you were right. There is a problem with the renderWholeZone function. I will go ahead and fix that before the next release. As for the normal rendering function, everything looks fine. The zone regions pop into view when they are needed. Remember there will be fog and clip in this zone as well.

Thanks for pointing this out to me though. I will go ahead and get it fixed up for the next release.

Cheers!

ableard · #**139** 03-28-2012, 03:15 PM

Very Good. So question about reading a zone of your own creation? Has this been revisited yet, besides azone. What is the limit in reading zones that you have run across, ie what era of
eq zones can you read?

cheers

PixelEngineer · #**140** 03-28-2012, 06:25 PM

Quote:

Originally Posted by ableard

Very Good. So question about reading a zone of your own creation? Has this been revisited yet, besides azone. What is the limit in reading zones that you have run across, ie what era of
eq zones can you read?

cheers

So far, the client has been tested with old zones and newer Luclin era versions of that same zone. I did away with SOIL (although a good library) because it was inflexible and I didn't really need it. All I need is the ability to load 8 bit bitmaps, to add an alpha channel to those and to load DDS format textures for the post Velious clients. I have no idea how it would react to the newest zones but I doubt I would get far seeing as how most of them are in a new format.

However, I may eventually add support for them. As far as our own zones, try it. I am sure they would load properly.

PixelEngineer · #**141** 04-04-2012, 02:57 AM

A proposal.

Hey everyone. I am still quite busy with school and such and I had a rather interesting idea. As I am pretty much a one man team working on an engine, I will likely never get this client up and running as solid as I have wanted. Sure, I will eventually implement full rendering, animation, UI and possibly client support but in a lot of those cases, I am reinventing the wheel.

I have had an idea that combines the work I have already done with a preexisting engine. I'd like to finish rendering with shaders, finish up some bugs and then switch to an open source engine. The problem with many EQ projects is that people try to convert the EverQuest format to a more common format and import it into an engine (Unity, Unreal, etc...) which is neither suited or optimized for the way the zones were originally created. What I propose is we pick an open source engine and load the EverQuest data into that.

I have had my eye on irrlicht, which is written in C++, is cross platform and has quite a few examples of loading Quake style BSP maps. The EverQuest format is similar and with the already extensive documentation of the fragments, I don't think porting my work would be that difficult.

The downside would be that I would no longer be working directly with the core engine code (although as it is open source, I could still see/modify it). The upside would be that a lot of the features that will take quite a while to implement (collision detection, per pixel light, parallax mapping) would be supported natively by the engine and I could focus on making sure the data from the zones are translated into this engine accurately.

I am very excited about the prospects of a quicker development cycle. I feel my learning of shaders thus far has been fantastic and I also realize that I will still learn a ton while working with an established engine especially because it is open source.

My plan is to finish up this next release of Lantern and then after that, begin the process of porting my work to the irrlicht engine.

Any comments/suggestion/criticism are welcome!

Cheers!

Tabasco · #**142** 04-04-2012, 09:18 AM

If you're going to use an engine I would suggest Ogre3d. I've used both and Ogre is much more capable and polished. It also has a better asset creation pipeline.
I'm sorry that I'm not able to dedicate more time to this, there just aren't enough hours in the day. When I do get a little time I'm not likely to get very far since the current SVN appears to be way behind and I don't know where the git repository is.
I would be more likely and able to work on it if commits were more frequent, maybe you could establish a release branch for feature complete updates that are sure to compile and keep the trunk always up to date.

**KLS** · #**143** 04-05-2012, 11:42 PM

I wrote my eqg loader in irr first then ogre3d (though the latter was a hacky mess as I was in the middle of getting advanced materials working). I'm not sure if they've changed anything recently with irr but it was a lot harder to work with the low level primitives that I needed to work with than it was in ogre.

The downside was ogre was a bigger set of dependencies to get up and running initially.

I also agree you shouldn't convert the assets, whatever you pick should just load them.

diriel · #**144** 05-04-2012, 02:07 AM

I read recently that Valve is porting Steam over to linux. This got me to thinking of this UI project. I have been following this with some interest from an end user standpoint.

Pretty cool work so far!

Tyen05 · #**145** 05-07-2012, 06:32 PM

Have you guys made any headway in porting animations over to a new engine?

PixelEngineer · #**146** 05-21-2012, 11:10 PM

Hey guys. A quick update. I have been finishing up another semester in school and have been pressed for time. I am going to have a pretty open summer and will likely finish the client as I can spend upwards of 40 hours a week on it. I have still been looking at different graphical engines. I really like what I see from Ogre3D and the ability to still do a majority of the logic work and have control over how the data is handled and yet, utilize the work the talented Ogre3D programmers have done on their graphics engine.

I will keep you posted. Expect big things.

PixelEngineer · #**147** 05-21-2012, 11:13 PM

Quote:

Originally Posted by Tyen05

Have you guys made any headway in porting animations over to a new engine?

Tyen05, as I mentioned before, porting the EQ zones to another engine is very hard. Importing them natively via code is a much better route. If I remember correctly, you are using Unity. You may in fact have to write a converter which takes EQ animation fragments and outputs them in a format Unity understand. I am not saying it is impossible but the exact issues you are having are the reason I have not decided to use a closed source engine.

Cheers!

diriel · #**148** 05-22-2012, 12:54 AM

Hi PixelEngineer,

I know when you started this thread you said you would never enable networking. I thought I would touch bases with you and see if you had perhaps had a change of heart at all. I for one would love an open source linux client

That would just rule.

That being said, once you feel satisfied you have got a solid grasp on the engine aspect, will you be developing an MMO?

Have a good one,
Diriel

Tyen05 · #**149** 05-28-2012, 08:47 PM

Quote:

Originally Posted by PixelEngineer

outputs them in a format Unity understand.
Cheers!

A format in which any 3d modelling software understands would be just as good. Such as Maya/3d max.

Tabasco · #**150** 05-29-2012, 07:42 AM

The hardest part of converting EQ zones is wrestling with the various file formats. It looks like WLD is a well understood format, but none of the existing work on EQG files gives me any texture information (or I haven't found it yet, OpenEQ source might be handy here but all the links are broken.)

This loads the .map files the servers read so some of the geometry is omitted, but it would be easy to tell azone to output mapfiles with full geometry if one wanted to.
http://dungeoncrawl.us.to/eq/mapvis/?zone=crushbone

For WLD zones those json map files could easily include textures and UV's. The only thing you lose is the EQ spatial database of choice. Most modern engines use an octree scene graph with frustum culling by default, so just breaking the zone geometry into reasonably sized chunks should be serviceable.
I have some progress on a zone converter that borrows heavily from azone2. It can output the zone model and all the placeable objects as individual model files, but textures are hit and miss.