Talk:DreamWipe

From Unify Community Wiki
Jump to: navigation, search

Very cool effect Eric; I can almost hear the "dream sequence sound"! Looking this over, shouldn't line 131 be:

transform.localScale = Vector3(-p.x, -p.y*2, 0.0);

instead of -p.x*2? Other wise, the x component is twice as wide as desired.--casemon 12:23, 23 July 2008 (PDT)

---

Nope, it's supposed to be x*2...the plane that the effect is placed on must be wider than the screen, or else you'd get the background showing through the gaps in the wavy edges. The plane is procedurally constructed with the intent that it be scaled twice as wide as the screen; the UVs make the edge pixels get stretched out. --Eric

---

Ahh indeed your right. It's interesting because with *2 it works in the player (tested on webplayer) but not in the editor (x0.87 works great in the editor, but not in players). I couldn't explain it.

Also, I'm seeing a very strange issue where in my test scene using this effect, the alpha of the created plane is somehow less than opaque, despite the plane's material being 100% opaque (prior to Hermite). The issue doesn't reproduce in your test scene (with the exact same code)! Any idea why the discrepancy? I've been tinkering with the shader, but alas, without a change to this issue.--casemon 03:57, 25 July 2008 (PDT)

---

I was going to say I've never had a problem, but with some more testing just now I can see it randomly fail in the editor. Very strange! It never happens when Maximize on Play is on, and only sometimes otherwise. Always works in builds though, but I can't imagine what would be causing it in the editor. I also can't reproduce the alpha thing, sorry.... --Eric

---

Per your PM, I uploaded a test package showing the alpha issue here. The script in the package is a little different from the original one, but I tested the issue against both & the same behavior results: the starting alpha of the created mesh is not 100% opaque, despite the material being 100% opaque. Can't' repro this in your test scene, even though i used the same exact camera & material settings. Also tested this with various other computers and had the same results.

Of the changes, you'll notice I made the effect a little more self-contained & even repeatable (although not in the editor, strangely) If we manage to sort this alpha issue out, and if you agree to the changes, will update the wiki with the resultant version as it's a little more flexible to use.

---

Using the default material has the alpha set wrong (for this effect). So I was able to fix the alpha problem in your test by making a material, setting opacity to 100%, and applying that to the objects. BTW you might want to look at the script again, as I simplified it a bit a little while ago by taking out the hermite function and replacing it with Mathf.SmoothStep, which basically does the same thing. --Eric

---

Interesting. Nothing in the effect seems to suggest why this wouldn't work with the default material... must be something strange with the Default-Diffuse material (just subbed a bug on it). Also, I can't figure out the 'wrong width in editor' bug... very strange.


Am updating the article now with a more "self contained" version including the following changes:

- spawns a new object instead of adding mesh filter and render, etc. to existing object. New object is child object that called it and is destroyed after the effect ends.

- effect is not in a single method call, no longer relies on Start method. You can just place it anywhere and call it on demand.

- method now takes 2 camera parameters (part of changes to make it more self-contained).

- demo scenes are repeatable (make the same call twice and it will swap cams the 2nd time).

- left in the old Hermite loop, as I found it to be more dreamy than the new SmoothStep (very jaggy). The SmoothStep code is still included, only commented out. (didn't have time to rewrite this so the types are both selectable & avoid using an enum).

- now works with cameras that appear anywhere in the hierarchy, instead of only in scene root.

- included additional demo scene (used simply to test these changes).

- default plane distance to cam is now lower and public var (was 1.0, now default is 0.0001); result is that the transition between start / stop of the effect is smoother (no "jump"). --casemon 11:08, 27 July 2008 (PDT)

---

Sorry to be a pain, but while it's totally cool that someone's using this script, I didn't actually agree with the changes, and I'm not fond of most of the new code so I put my version back.

For example, the fxPlaneOffset variable adds unnecessary complication; at least in my code, it's completely arbitrary as long as it's less than 0; it can be -1, -10, -1000, or whatever and there's zero difference in how it looks. Mathf.SmoothStep IS the hermite function internally (at least I assume so since that's how SmoothStep is normally implemented), so you might as well let Unity take care of the scary math stuff and make the code shorter and nicer. Not sure what would mess it up with the new code; with mine it looks exactly the same, since the actual math is the same. I don't see the point in removing the enum, which makes it nicer to use in the Inspector...if it's a boolean, the choice is hermite or not...but what's "not"? There's no way to tell for sure without reading the code. Making the function more independent is a nice idea, but at least on my machine I get a small framerate hiccup the first time it's used unless it's set up ahead of time.

Good catch on the camera not working properly except at root, so I fixed that, and the shader additions are a good thing so I used them too. Strangely, I can't get the editor bug to happen anymore...no idea what's up with that.... --Eric

---

Hmm... I'm surprised you chose to revert, as most of the changes were performed in the spirit of wiki to make the script easier to use or more flexible to use.

To answer your specific questions, comments:

  • re: "offset" Added this as I was seeing strange hiccups in the transition due to the larger distance. The distance of the original made it so the transition wasn't as smooth as it could be. Not sure if this is related to the other weird editor behavior this effect experienced.
  • re: "Change to Hermite": the previous loop did not work with the more self-contained version for some reason. The replacement is more or less the same, just written differently, as you pointed out and not terribly longer, so where's the harm?
  • re: "shorter and nicer" All good and well, until it's at the cost of flexibility and thus usability.
  • re: "Why remove the enum?": No important reason, just thought it silly to have an enum for a grande total of 2 values; if something is "either or" then why not just use a boolean?
  • re: "self contained changes" Couple of reasons: More OOP is easier to use and adapt if one so chooses. Further, was done to reduce the setup required on the object; 'automagic' usually means more useful. Adding, it is possible to work around the "hiccup" you're seeing with only minor changes (though I'm not seeing it on my machine).
  • re: "Other changes" so that the effect is more flexible & even repeatable (and thus arguably more usable) in real-world scenarios (not just isolated test scene where cameras are at root, etc.).

Thinking if the refined version works in more cases, requires less setup of the base object by the user, is more re-usable and self-contained, offers additional scene advantages, and isn't terribly longer or more complicated, where's the offense? (I'm guessing ego, but could be wrong).

In any case, it begs the question: "What's the point of the wiki if not to build on shared contributions for the better?" --casemon 03:35, 15 August 2008 (PDT)

---

I have no problems with my code being refined and improved; in fact I'd welcome that. That would save me the bother of having to do it myself.  ;) The only problem here being that I don't think the code was particularly improved in this case. I've learned a fair bit from code on the wiki, so I'd prefer to promote cleaner and more understandable code, and the replacement was a bit of a mess IMO. I did explain the reasons for things like enums, which you can read above (additionally, it's more flexible to keep it an enum in case I or someone else adds additional options in the future...it's not something that's inherently locked to two values). I think something being on the wiki means everyone gets a say, including the original author, so we'll just have to agree to disagree here. --Eric

Personal tools
Namespaces

Variants
Actions
Navigation
Extras
Toolbox