roq effects

[Tels]

I implemented the rotoscope shader because it already worked for Doom 3 specifically. The shader thing you mentioned above - would that work with doom3 or would it have to be modified quite a bit to be implemented?

 

Don't ask me, I just used google. Maybe if you read the links I posted you can find out (Most shaders should work with doom, tho)

 

The rotoscope shader took all of 5 minutes to implement, and I did that, so it was no detraction from the coders etc. For example, there is no way I could code AI.

 

I don't complain about it, it is very cool. But i get annoyed that whenever someone poses an idea, people spent way longer to tell the person in question "that is too complicated", "that won't work", "nobody has time", "not needed", than it would take to just do it in some cases.

 

(I bet you would have gotten the same responses if you asked first about the rotoscope thing instead of just implementing it and showing it. Hm, I guess I just learned a lesson

 

Anyway, bed time for me now, I start to get grumpy

[SneaksieDave]

I believe keeping it 'under wraps until it was ready' was the case with Gildoran's implementation of readables, and it's turned out to be a beloved feature.

[greebo]

(I bet you would have gotten the same responses if you asked first about the rotoscope thing instead of just implementing it and showing it. Hm, I guess I just learned a lesson

 

There's some truth in that. And I always get the impression that the team is arguing way too much over fine details, which takes an awful lot of energy from all who are involved. Of course, we're communicating over teh intarnet and forum discussions are always slow, so that's partially unavoidable. I guess most of the things we discussed in 13 pages could be solved by a real-life meeting in about half an hour.

 

Anyways, it's at least necessary to agree on the rough plan of what you're going to implement. Much the same way I asked the other coders about refactoring the AI code into the SDK. If I posted any imlementation details, I wouldn't have started yet, I reckon.

[Dram]

I guess most of the things we discussed in 13 pages could be solved by a real-life meeting in about half an hour.

 

To quote Renzatic from a while back: One big punch-up

[Tels]

To quote Renzatic from a while back: One big punch-up

 

Well, I guess we wouldn't even reach the meeting, I guess, instead getting arrested on charges of terrorism. I mean, dark-hooded, bow-concealing, blackjack-toting shady figures that jump from dark corner to corner - yikes!

 

PS: I agree with greebo here that at least some outline is necessary. But a lot of time is spent on discussion and explaining minor details, or what a fix could be, instead of just fixing it on way or another.

[Ishtvan]

One problem is that everyone has their own vision of what their perfect mod would be, and we have to make some compromises when opinions differ.

 

I don't think there is a general reaction of "that's too complicated," though. When people ask how easy it is to implement something, I give an honest opinion based on what I know of the SDK. Sometimes the answer is "that would take 5 minutes," sometimes it is "you would have to rewrite this whole system that took 200 hours to write the first time." And of course if the task would take hundreds of man-hours to do, we have to think about whether it's worth it and what priority it has in the overall mod, because we do actually want to release some day.

 

You can work on implementing anything you want, but if you don't discuss it with people first, there is a very real risk that the majority of people won't like what you've changed or won't particularly want the feature you've added. Then you've got a fine mini-mod for yourself, but the actual mod progress has not advanced.

[Springheel]

Very well put, Ishtvan. We had our heady days of proposing this and that cool feature during the first two years of the mod. Then we realized that if we actually wanted to be able to release a completed mod in a realistic period of time, we were going to have to start being selective about what was worth doing and what wasn't. Obviously opinions sometimes differ.

[Ishtvan]

Just an update, I finally tested the roq candles. They looked decent, although maybe less believable than particles when the candle was rotated on its side, because the image obviously rotated and the bottom of the candle flame was coming from emtpy space below the sideways candle. I did have a bug where I got a second copy of the image below the other (so it went candle flame, bottom of candle flame, top 1/3rd of candle flame). I'm using ATI R9800Pro.

[Dram]

Ok, well does'nt matter then - I'll put back the old particle effect as I truly cannot be screwed playing around with this at the moment - too much uni work to do etc

[SneaksieDave]

I think we should definitely keep both, as options for the user. A few lines of text in a particle file, and a small movie file or two never hurt anyone. In some cases, a user might want really realistic looking roqs, and in another case, it might be more important to have view accuracy from all angles, in which case they can choose the particle. It's just more tools in the kit.

[Komag]

But if they tilt when you lean I don't see how that could ever be desireable (although I guess leaning doesn't happen all that often, so maybe it would be okay)

[Springheel]

The roq atm isn't fully workable, as I understand it (I still see only the glow, no flame at all). We don't want to leave stuff in that's only half-finished.

[sparhawk]

Yeah. Either make it completed or leave it out. Such half assed solutions, only bloat the download and after a few months nobody knows what it was supposed to do.

If you want to keep it you can document it on the WIKI and make a local backup of the relevant files.

[SneaksieDave]

That's fine, too. Didn't realize people had problems with it. Works fine here (and looks quite good, aside from the limitations of using flat images for essentially 3D objects).

[Tels]

The roq atm isn't fully workable, as I understand it (I still see only the glow, no flame at all). We don't want to leave stuff in that's only half-finished.

 

They work fine for me. (except the problem that extingushing the candle did leave some after-effect for a random while)

[Springheel]

They work fine for me. (except the problem that extingushing the candle did leave some after-effect for a random while)

 

In other words, there are problems.

 

If they can be addressed and fixed, then great, we can add it as an option. Until then, it should be left out.

[Tels]

In other words, there are problems.

 

It was my impression Dram already knew why this is happens and a fix should come "any minute now". But maybe I misinterpreted his post.

 

If they can be addressed and fixed, then great, we can add it as an option. Until then, it should be left out.

 

While I generally agree with this direction, we have so much half-finishes stuff in, that I wonder a bit why the sudden urge to throw away this nice work.

 

For instance, there is still the broken imp coins and a map that no longer works, and my pleas to remove this have ended somewhere in a discussion...

 

So can we leave this in please, so someone can have a stab at fixing them? For unmoving candles on a wall, they look great so far.

[Springheel]

For instance, there is still the broken imp coins and a map that no longer works, and my pleas to remove this have ended somewhere in a discussion...

 

Maps and assets are two different things (though I can't see any reason to keep that particular map, personally). A half-finished map doesn't affect anyone else's efforts. A half-finished asset can lead a mapper into believing that it is ready to use.

[Dram]

It is easy to fix the issue of it not disappearing after being extinguished etc as that is related to particle lifespan. As for it not showing up for some - I have no idea why. I'll fix it and add is as a separate thing for people to use. But I seriously cannot be screwed with this at the moment, so I'll just put back the old one and move the roq version to a different particle file for now. I've got lots of worries at uni, and I don't have enough motivation to go and try to fix this issue now. But I'll quickly move the roq flame to a different file.

[Ishtvan]

While I generally agree with this direction, we have so much half-finishes stuff in, that I wonder a bit why the sudden urge to throw away this nice work.

 

For instance, there is still the broken imp coins and a map that no longer works, and my pleas to remove this have ended somewhere in a discussion...

I didn't know you were so adamant about removing a map designed to test scriptfunctions that alter the AI friend/enemy relationships dynamically. What do you have against testing script functions? I'm sorry I haven't fixed it yet, I've been either at work or asleep for the past 3 days. If you want to fix the map, go ahead.

[Springheel]

The first critique above, about the view alignment - it is also affected by leaning. So if you lean, the flames lean with you. I don't honestly know if there's a way around this, because it is an image -- the same problem existed with the very first flames -- they only looked right under face-on conditions.

 

Forgive the thread necromancy....

 

Anyone know what the difference is between a particle and a sprite in this case? Particles are just 2-poly squares, so what is it about them that keeps the orientation proper compared to a 2-poly sprite?

[Tels]

Forgive the thread necromancy....

 

Anyone know what the difference is between a particle and a sprite in this case? Particles are just 2-poly squares, so what is it about them that keeps the orientation proper compared to a 2-poly sprite?

 

Probably a keyword like "player-orientated".

 

I think in the particle files that would be this line:

 

orientation					 view

[OrbWeaver]

Anyone know what the difference is between a particle and a sprite in this case? Particles are just 2-poly squares, so what is it about them that keeps the orientation proper compared to a 2-poly sprite?

 

Are you asking about the conceptual difference, or a particular Doom 3 keyword, like "deform sprite"?

 

Conceptually a "sprite" refers to any 2D image which is rendered onto a quad turned to face the player, whereas "particles" are a series of 2D quads which are emitted at a particular size/velocity/direction from an emitter. Particles are usually sprites, but not all sprites are particles (if there is only a single static one, for example).

 

If you are referring to deform sprite versus deform particle, I believe the difference is that deform sprite causes the quad onto which the material is applied to be rotated to face the player, whereas deform particle causes the surface to emit particles using the .prt definition supplied as a parameter.

[Springheel]

I'm asking more to solve a particular problem.

 

Our particle candle flame has some aesthetic issues, but cannot really be made any more flame-like. Trying to add any more waver just causes the flame to break up.

 

Static sprite candleflames can be made using rotation and translation tables to simulate a flickering flame (like the original D3 candles), but when you look at them from the top, they don't look right (and also they supposedly move when you lean?).

 

I was wondering what it was about particles that keep them looking good from odd angles--we could make a much better flame if we could combine the aesthetics of a sprite with the orientation of a particle.

[SneaksieDave]

Our particle candle flame has some aesthetic issues, but cannot really be made any more flame-like. Trying to add any more waver just causes the flame to break up.

Yep; the waver was instead done to the particle emitter itself to prevent that. Not perfect, but it works decently.

 

The flame should already be oriented in a manner that the flame has a top and bottom, and stays aligned with the candle (for the most part) if that's what you mean. Recall we tried the roqs before and they had the problems of both repeating noticeably (as opposed to random particle generation) and were very 2D looking, because they either rotated with the player view (looks wrong at any but level, face on view, because it rotates (no top/bottom)) or had to be hard aligned (looks wrong from any angle except the angle facing the flat surface).

 

Thus, though I don't know for sure, I'd guess the roqs would always be like a sheet and be stuck with that limitation, while the particles are view oriented, and generated in 3D space to make them appear 'full'.