Jump to content
Eternal Lands Official Forums
Entropy

Special effects

Recommended Posts

Another good day. Smoke + Bag pickup/dropping done.

 

Remaining:

Clouds

Random harvesting events

One more optimization (trimming/scaling particle textures)

OPTIONAL: Deterministic firefly positions for firefly effect (already coded)

OPTIONAL: Blowing leaves/flower petals, based on firefly effect.

OPTIONAL: Auto-adjust LOD when we near our particle limit.

Merge code from sandbox into the game.

Test, test, test.

Share this post


Link to post
Share on other sites

Clouds are "done". Done in quotes because I'm getting some flickering, but I think it's due to this laptop's funky video card and its occasional problems with OpenGL. (I'll try them out on my PC later).

 

Moving on to random harvesting events!

Share this post


Link to post
Share on other sites

Random harvesting effects are done.

Pics of leaves and flower petals at different angles have been taken. I'll offload them tomorrow and work on the blowing leaves/petals effect, then call that the last one. After that:

 

One optimization

Merge code into the game

Test, test, test!

Share this post


Link to post
Share on other sites

Random harvesting effects are done.

Pics of leaves and flower petals at different angles have been taken. I'll offload them tomorrow and work on the blowing leaves/petals effect, then call that the last one. After that:

 

One optimization

Merge code into the game

Test, test, test!

 

Excellent :doze:

We can release a test client after the update, and make it optional for people to use it, if they want to.

Share this post


Link to post
Share on other sites

Sorry for the delays, everyone. :) I'm back from xmas break. Good news and bad news.

 

Bad: I came home and my DSL gateway is frotzed. That means I can only get online from work, which means little time online to post. It also means that I can't grab the CVS tree, and that my web server is down.

 

Good: Over Xmas break, I finished the blowing leaves/flower petals effect and the dragon breath effect. That's the whole list. Up next, a few optimizations, and then I need to start working it into EL.

 

A few notes: Blowing leaves/petals are made of textured polys for realism; I found it was necessary. They're two poly triangle fans so that they're not one dimensional, so they don't disappear when looked at from the side. The dragon effect not only deals with fire breathing dragons, but is ready for any future dragons -- presets currently include fire, ice, lightning, magic, poison, and wind breath, and can be expanded as necessary.

Edited by KarenRei

Share this post


Link to post
Share on other sites

It depends on how distracted I get. :) They're already quite stable, but they're not incorporated into the game yet; I've been using my own test environment to make it easier to debug.

To save you some time when it comes to integration, the right hand bone (which I assume roja will use for animations? I could be wrong) is boneId 25, ie.

 

float points[1024][3];
float x, y, z;

CalSkeleton_GetBonePoints(CalModel_GetSkeleton(actor->calmodel), &points[0][0]);
x = points[25][0];
y = points[25][1];
z = points[25][2];

I don't think we can assume any bone numbers, I'd rather see the bone number defined in the actor's XML file. That way as new monsters and races are added it's easier for effect to be on them and the current ones ... just think of a spell being cast by a goblin!

Share this post


Link to post
Share on other sites

Well, I didn't finish up optimization this weekend, but I got close.

 

Did:

* Moved to different computer with a newer compiler. Found that it introduced some bugs with -O3. Tracked them down and wrapped the relevant sections in __attribute__ ((noinline)) to stop the compiler from being too intelligent.

* Added -Wall -Werror to my compilation options, and made build.

* Changed almost all floats and doubles to typedef'ed types.

* Optimized those types; was able to eliminate all use of doubles, even on cases where I was worried about precision.

* Restored particle count limits with additional error checking (which turns out to actually speed up the program)

* Automatic LOD adjusting when the particle count nears its limit. It's fast, and surprisingly effective. This means that if dozens of people are all casting spells at the same time during an invasion or something, you'll still be able to see all of the effects -- just at low LOD.

* Started the process of trimming down textures; I want them to be high enough res that you don't usually notice that they're textures, but no higher. I'll need to experiment to find out where that limit is.

 

Still need to do:

* Finish the process of trimming down textures. Currently encountering a bug: all I did was change the textures from 128x128 to 96x96 (some by scaling, some by cropping), and adjusted the particle sizes spawned in code, but it's now repeatedly hanging on glFlush. Need to figure this one out. :)

 

After that one issue, I'll be done with optimization for now, and I'll be ready to start on integration with EL. Game plan for that:

 

1) Get my code to build with the EL build process as an external library.

2) Make a wrapper, ala cal3d.

3) Spawn an effect within EL, not triggered by anything -- just running by default when you start up the client (in order test it out).

4a) Adjust effect scaling, GL flags, and anything needed to make the effect look right within the EL client.

4b) Same for map editor.

5a) Begin the process of tying in effects to where in the game they belong. This will undoubtedly require serverside hooks in a number of places.

5b) Same for map editor.

6) Once that is done for all effects, release and switch into maintenence/bugfix mode.

7) Finally relax. :)

 

I imagine this process will take at least several weeks, possibly a few months. We'll have to see how it goes.

Share this post


Link to post
Share on other sites

Currently encountering a bug: all I did was change the textures from 128x128 to 96x96 (some by scaling, some by cropping), and adjusted the particle sizes spawned in code, but it's now repeatedly hanging on glFlush. Need to figure this one out. :)

 

 

I think you have to stick with the 16x16, 32, 64, 128, 256, 512 sizes only. Was never able to use anything else.

Share this post


Link to post
Share on other sites

That was my suspicion (I'd run into something like this before), but at 1:30 AM last night when I ran into this, it was too test it out. :( Thanks! I was hoping "divisible by 32" was good enough, but I guess it's only powers of two that work right.

Share this post


Link to post
Share on other sites

The a gl extension GL_ARB_texture_non_power_of_two is on at least some video cards (my geforce go 6150, at least), if 98x98 textures improves performance enough to bother checking for it (and it would be any faster once you use the extension).

 

Disclaimer: I no nothing of opengl.

Edited by freeone3000

Share this post


Link to post
Share on other sites

Probably not worth the effort. 96 was just convenient for me to trim to, but I've already spent the time to make 16x16, 32x32, 64x64, and 128x128 variants of the textures and implemented code to use the appropriate res texture based on how big the particle is. Still needs a bit of refining (some of the textures have visible boundaries at texture edge instead of fading completely to transparency, and some of the particles are disproportionately sized in some effects now), but then it'll be done and I can move on to integration.

 

Thanks, though ;)

Share this post


Link to post
Share on other sites

The a gl extension GL_ARB_texture_non_power_of_two is on at least some video cards (my geforce go 6150, at least), if 98x98 textures improves performance enough to bother checking for it (and it would be any faster once you use the extension).

 

Disclaimer: I no nothing of opengl.

 

Unfortunately, a lot of video cards do not support it, so it's not an option yet (unless if an alternative coding path is added to work on cards that do not support it too).

Share this post


Link to post
Share on other sites

Yeah, I prefer to keep the requirements simple. All I require is GL_POINT_SPRITE_ARB. If it came down to it, I could even remove that requirement by making an optional (slower) draw function that uses billboarded quads.

 

I finished redoing the texture optimization last night. I noticed one other thing that I want to fix, though -- the wind effect sometimes clusters leaves in little vortices, and I'm not sure why. It's good to have them swirl, but it doesn't look right if they're caught for long periods and wedged close together. Once I get that done, I'll make one final release of the standalone eye candy demonstrator and move on to integration.

Edited by KarenRei

Share this post


Link to post
Share on other sites

Yeah, I prefer to keep the requirements simple. All I require is GL_POINT_SPRITE_ARB. If it came down to it, I could even remove that requirement by making an optional (slower) draw function that uses billboarded quads.

 

Many cards do not support than extension. Some ATI cards report the extension as being available, but it's mallfunctioning.

Share this post


Link to post
Share on other sites

Hmm. I guess the option to use quads is necessary, then; I don't want to leave older video cards in the dark. Darn. I was about to come here to report that I finished the standalone version and was ready to start integrating it with EL. I guess it'll be another day or two, then.

 

The last bug (where leaves would cluster into vortices) was a particularly sneaky one. I was adding a floating point casting of the time into the argument to sin() when determining the local force vector, to make it so that no region in which forces cancelled out (vortices) would remain stable over time. Yet they never seemed to shift. Reason: The loss of precision when converting to floating point dropped the lower order bits. Oy.

 

So, anyways: I'm done with the standalone version *except* for the option to use quads, which I'll start work on tomorrow. Know a good way to detect whether glGetString(GL_EXTENSIONS) is lying about GL_ARB_point_parameters?

Share this post


Link to post
Share on other sites

Okay -- done. Version 1.3 is released and on the website. It now has the ability to draw both with simplified billboarded quads and true billboarded quads. Performance actually went up on this ati card I'm testing on, heh. :happy:

 

Tomorrow, step one of integration: getting it to build with EL.

Share this post


Link to post
Share on other sites

The a gl extension GL_ARB_texture_non_power_of_two is on at least some video cards (my geforce go 6150, at least), if 98x98 textures improves performance enough to bother checking for it (and it would be any faster once you use the extension).

 

Disclaimer: I no nothing of opengl.

 

Unfortunately, a lot of video cards do not support it, so it's not an option yet (unless if an alternative coding path is added to work on cards that do not support it too).

You can actually load a NPOT image in a POT texture and use some tricks when blitting it in order to take into account dimension differences, like I did in my GL_blit demo here: http://autistici.org/encelo/prog_gldemos.php

We have adopted the code (and fixed some issues) and integrated it inside the game Mars: Land of No Mercy, have a read here: http://mars.svn.sourceforge.net/viewvc/mar...cpp?view=markup

Share this post


Link to post
Share on other sites

In order to determine if the point sprites ext should be used or not, use the same setting that renders the particles with quads or pointsprites. The option is in the configuration window of the client.

Share this post


Link to post
Share on other sites

Just a note: I'm going to be waylaid for a few weeks. My younger sister is engaged, and she wants me to make her wedding website. And I'm not about to pump out a piece of garbage for it, so... I'll be back in a few.

Share this post


Link to post
Share on other sites

Sure, don't worry.

Hopefully, you can have something by late march maybe?

We would like to have another client update in April or so.

Share this post


Link to post
Share on other sites

I hope this fits in here:

 

What about a special (visual) effect for being poisoned? Especially the new Mushroom poison.

 

My idea would be a add a semi-transparent Layer over the client window's render area and change that layer's color randomly :ph34r:

 

Regards

 

Flo

Share this post


Link to post
Share on other sites

Hallucinating again? I was thinking about this for TS also. Make the window a little brighter . For invisibility could make the screen a bit bluer.

Share this post


Link to post
Share on other sites

I hope this fits in here:

 

What about a special (visual) effect for being poisoned? Especially the new Mushroom poison.

 

My idea would be a add a semi-transparent Layer over the client window's render area and change that layer's color randomly :(

 

 

 

Isn't there a little poison icon that comes up in the corner? If not, there should be. I would not support coloring the ENTIRE view area at all, any shade.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Recently Browsing   0 members

    No registered users viewing this page.

×