Unity erase parts of an image - graphics

Good day, I was wondering on how can I implement an effect like the ones on the sweepstakes where you scratch the grey part and reveal a number underneath it. I was wondering how can I implement that in unity, I don't have any clue where to start, thanks in advance.
the idea is, I have 2 overlapping objects, A and B, whereas when I click on a part of B it will be removed and will show a part of A, both A and B are sprite images though

This is not really related to Unity as such. This relates more to a general technical solution for a visual representation you would like to do.
So, let's skip the Unity part.
But even then the question is very general and hard to respond to. There are many ways to achieve this, depending on the result you want.
You could apply a quad object, with a grey texture on top of whatever number box you have and then either use shaders to show the number as you "scratch it". Or you could remove the grey square when clicking it (different behaviour). Or you could do the old school approach and replace pixels, as you "scratch" the box.
Only to mention a few ideas.
But still, the question is very general and hard to answer as it pertains to a general idea, and not so much a concrete question.

Look into how to build Fog of war shader. I would achieve this by rendering A and B with two separate cameras then as you scratch it off it would reveal B in the scratched area.

Related

How did Epic Games achieve this 3D effect on their Fortnite site?

I have been looking at Epic Games' Fortnites Website and I am trying to figure out how they achieved the 3D effect on the page:
Epic Games' Fortnite website - scrolled down to 3rd slide
Does any one have any idea how to do it? I would really like something similar to a project I'm working on. I have found Three.js, but I am quite sure that is not the solution they went with.
For these types of questions, i can only recommend to install spector.js and have a look yourself. In short: everything you see is 100% faked.
I mean, that's always the case. In fact, if you want to build something like that, your first question should always be: how much of this can I fake and still get away with that?
In this example, it turns out: everything. Just open the devtools and click through all the assets in the network-tab. You will find these two textures:
looks familiar, right?
So what they appear to be doing is they are using three.js with some custom shaders to handle the translations, the flickering of the lights and the highlighting. These effects are computed using the normal-map and an additional mask-texture which I couldn't quite figure out what it does. But again, if you look at the scene in spector.js you can see the shaders used for every drawcall.
The only thing that is a bit more complex is the little robot-friend in the bottom left corner. But again, it's not 3d as in meshes and so on but rather a set of flat textured quads running a bones-animation thing.
I think that makes it a really great website after all.
Given that epic is building the unreal-engine I would suspect the original renders were done there. And I agree, the lighting looks really amazing :)
It is a simple parallax effect using animated sprite sheets.
Parallax effect is achieved by using several layers of images/video on top of one another in different Z-depth.
You can achieve the moving part by using the mousemove event to track the cursor.

GtkFrame mystery: Different looks each time the program is started

This is really confusing the heck out of me. Take a look at this screenshot:
Sometimes, the GtkFrames in my program look like on the left side, and sometimes they look like on the right side - or even a mix of the two! The program is exactly the same. Just running the same program multiple times yields very different looks of the GtkFrames in the program! How can that be?
It seems that there are two different designs of GtkFrame:
The first one has its label centered at the top of the frame and
smoothly dissolves towards the
bottom so that the frame doesn't completely enclose the GtkFrame's
contents.
The second design has its label left-aligned at the top of the frame
and draws a border around the complete GtkFrame.
The problem is now that GTK+ seems to choose one of the two designs entirely at random. I don't see any pattern in which design I'm going to get. It appears to happen completely at random which is really confusing me.
Can somebody shed a light onto this mystery? What is going on here? Is there a way to force GTK+ to use a certain design?
I'm using GTK+ 2.24.10 with the Adwaita theme on Linux Mint.

How do I create a real-time rendering window from scratch?

I've been studying 3D graphics on my own for a while now and I want to get a greater understanding of just how everything works. What I would like to do is to create a simple game without using DirectX or OpenGL. I understand most of the math I believe, but the problem I am running up against is I do not know how to get control of the pixels being displayed in a window.
How do I specify what color I want each pixel in my window to be?
I understand I will probably run into issues with buffers and image shearing and probably terrible efficiency problems, but I want to create my own program so that I could see from the very lowest level, of the high level language, how the rendering process works. I really have no idea where to start though. I've figured out how to output BMPs, but I would like to have a running program spitting out 20+ frames per second. How do I accomplish this?
You could pick a environment that allows you to fill an array with values for pixels and display it as a bitmap. This way you come closest to poking RGB values in video memory. WPF, Silverlight, HTML5/Javascript can do this. If you do not make it full screen these technologies should suffice for now.
In WPF and Silverlight, use the WriteableBitmap.
In HTML5, use the canvas
Then it is up to you to implement the logic to draw lines, circles, bezier curves, 3D projections.
This is a lot of fun and you will learn a lot.
I'm reading between the lines that you're more interested in having full control over the rendering process from a low level, rather than having a specific interest in how to achieve that on one specific platform.
If that's the case then you will probably get a good bang for your buck looking at a library like SDL which provides you with a frame buffer that you can render to directly but abstracts away a lot of the platform specifics issues. It has been around for quite a while and there are some good tutorials to give you an idea of whether it's the kind of thing you're looking for - see this tutorial and the subsequent one in the same series, which should be enough to get you up and running.
You say you want to create some kind of a rendering engine, meaning desinging you own Pipeline and matrice classes. Which you are to use to transform 3D coordinates to 2D points.
When you have got the 2D points you've been looking for. You can use say for instance on windows, you can select a brush and draw you triangle values while coloring them at the same time.
I do not know why you would need Bitmaps, but if you want to practice say Texturing you can also do that yourself although off course on a weak computer this might take your frames per second significantly.
If you aim is to understand how rendering works on the lowest level. This is with no doubt a good practice.
Jt Schwinschwiga

How to implement old film effect?

I'd like to implement an old film effect on pictures. Does anyone know a library or even the rare maths involved? I'd like it to cope with red shift for over-exposition and the rest. Even if you don't know the maths or a library, a pointer to any technical doc will be appreciated.
Clarification: I need to write these routines for a project of my own. I'd like to know what kind of processing has to be done and how. Doesn't matter the environment and system, I just need some hint on how process RGB data
You mention Magic Bullet from Red Giant Software in your comments. There's an impressive amount of image processing know-how behind the development of Magic Bullet. You'd probably have an easier time implementing a host interface for After Effects or Final Cut Pro plug-ins and using Magic Bullet.
If you want to see some source code in action, examine the open source projects that do image processing like GIMP, CinePaint, FreeFrame, etc.
You could try with as3 bitmapdata noise function http://livedocs.adobe.com/flash/9.0/ActionScriptLangRefV3/flash/display/BitmapData.html#noise%28%29
If you can find a plugin for Paint.Net, I'm sure you could just use that dll in your program. Is this the sort of thing you're looking for?
Rare maths?
Create several different transparent PNGs with scratch and dust marks on it. Take a pic, adjust the hue, saturation and brightness (algorithms for this aren't that complex) to fade out the pic, then overlay one to many of the scratchy PNGs. The more scratch/dust PNGs you have, the more random the effect you can create.
Not much math here IMHO.

Why would you choose a fixed-width design?

Update:
I deleted my motivation because it seems to distract readers. This is not about "why don't you make your window smaller". See the screenshots and you will see obstructed text because of fixed width. See my reference to "em/ex" notation in CSS. I would like to have a real discussion here. Thank you.
Now I would like to ask real experts on this topic -- I'm not a web designer -- why fixed width layout are still that popular and if there are really good reasons for it. (you are welcome to point out reasons against it as well.)
Is it too hard to design your layout relatively (from start on)? It seems some people even forgot how to do it.
Do you have real reasons like readability and just don't know how to deal with it correctly? Here I'm referring to pieces of wisdom, like it's harder to read longer lines (that's why newspapers use columns) -- but then, width should be given using em and ex.
Are you forced by some old guidelines? In the dark old age of HTML, people did a lot of things wrong; now everybody finally uses CSS, but perhaps this one just sticked.
Or are you like me, wondering why everybody is doing it "wrong"?
To illustrate the issue, I want to give screenshots of negative examples first:
StackOverflow (here I can't even see what would make it any hard to fix it)
Filmstarts (a german website which renders itself unreadable-if I don't take a reading-glass with me)
And here is a positive example. It looks like a typical fixed with site (even with transparent borders), but it is not:
Website on Wiki software -- associated Forums
What do you think?
Update: Related questions: this one and that one.
And here, as expected, comes the usual canard: “long lines are too hard to read”.
[Citation needed], folks.
See http://webusability.com/article_line_length_12_2002.htm for a summary of actual research in this area. A number of these, plus http://psychology.wichita.edu/surl/usabilitynews/72/LineLength.asp, find that although users express a preference for moderate line lengths, reading speeds do not sharply drop off with ‘long’ lines; in fact many show increased speeds with the longer settings.
As long as it's not ridiculously long, and taking care to use a decent amount of leading, long lines are not generally a real issue at today's typical browser widths and default font sizes. (If you're one of those designers that loves to use teeny-tiny type for everything, it could be an issue, but then you're already making it impossible to read with the flyspeck text. Stop it!)
So as it's only an option of user preference that prefers medium-short lines, let us users decide how much screen space we want to give the web site to get our work done. We're the ones best-equipped to know. If you decide you know definitively best you're likely to waste space, or, if you guessed too long, make us scroll back and forth sideways to read the text — and that really is a readability nightmare.
If you want to protect us from ourselves, you can compromise by specifying a min-width and max-width in ‘em’ units so that the page is responsive to liquid layout, but doesn't get stretched to extremes.
But otherwise, the best reason to design fixed-width is indeed that it is easier, especially for someone with a fixed-2D-grid view of the world and static visual-design tools like Photoshop.
It's already a pain to make a website that renders correctly across all popular browsers; if you also want it to render correctly at all text sizes, it's quite a lot of work. A lot of web developers design their sites for the default font size and try to support fonts that are either a little bit larger or a little bit smaller. (You might be interested in this dated but relevant piece from Jakob Nielsen.)
As for fixed-width sites, it's hard to say. Personally, I suspect that a lot of web designers just like to feel like they have a lot of control over their look and feel, and think the site looks "ugly" when you stretch it too far, so they don't let you do it. Probably not wise, but there you go.
Now I would like to ask real experts
on this topic -- I'm not a web
designer -- why fixed width layout are
still that popular and if there are
really good reasons for it.
Ah, both subjective and argumentative. I'm sure my argument won't convince you, but here's one really good reason, IMHO:
Presentation.
Just like a movie, the director has an experience in mind for the viewer. They frame the movie just so. They move the action at a given pace for the emotion they are trying to invoke in the viewer. Even though DVDs have had the "angle" feature since inception, few movies have ever given viewers the opportunity to watch the film from a different point of view, and if they have that viewpoint was still under the control of the director.
Now, any old sap can throw up a website, and for the most part they aren't interested in anything more than the content.
But real designers fully understand that the design must be understood as a whole. A wide layout has a very different impact on people than a multicolumn or thin layout. Reader eyes move in a certain pattern, and the text is intended to pull the reader along a path.
Those who claim that every layout should have certain features are shortsighted. There are no universally true 'rules', and trying to make an expanding layout a rule is shortsighted at best, and arrogant at worst.
-Adam
Here are my $0.02 and they are worth exactly what you paid for them (and if that's not a perfect example of the current economic situation... :-))
The layout of a website should be dictated by the overall user experience. This is in part determined by the accessibility, in part by the design, in part by the functionality:
Accessibility - as several people pointed out, letting the website use the full width of the browser without any control can result in quite a long lines that make it hard to read[1]. Making the text automatically layout in multiple columns is a potential answer to this problem, but it's really hard to achieve with CSS (that's gotta be the worst tool for doing layout humanity ever devised, but that's a separate topic) and is fraught with other issues as well.
I should note that you do have a point - most websites with fixed width do suck on high-DPI because they don't take into account the changed font size. However, that's not an inherent problem of the fixed width design; I've seen it with fluid designs as well.
[1] No, I don't have a citation. I, however, have tried reading on full-screen on my 24" 1920x1200 96dpi [2] and gotta tell you - after 15 minutes my neck is cramping from the constant turning of my head.
[2] The typical user still runs 1024x768 or 1280x1024 (based on instrumentation from the product I work on, with about little bit less than 10mln installs for the latest version). So yeah, I am not the typical user.
Design - most modern designs are very rich on graphical and video elements. Most graphical elements do not scale well with the document reflow and video does not scale at all. (I would again blame this on CSS - it's support for dynamic resizing of images is lacking some basic operations and there is aboslutely no support for building and control of the visual tree. But I digress again :-)) As such, disegners opt in for the easier approach.
Functionality - fluid layout is really good for dealing with big text chunks like documents. However, quite a few modern websites are in effect applications, not documents. They have multiple elements and controls and increasing the area on which these elements are scatered makes it harder for the user to keep all of them in focus.
Couple examples:
two control groups that are aligned at the left and the right end will be too far away from each other in full-screen width. Note: that can be alleviated by choosing to always keep all the controls grouped together, like most desktop applications do (almost all desktop apps keep all toolbars left-aligned).
a picture/video and associated text below it. On full screen there are two possible approaches for fluid layout:
a) scale the picture to the full width, at which point the text is visually lost
b) leave the picture the same width, but let the text flow the full width, at which point the picture is visually lost.
I guess my point is that the fluid layout is not the Holy Grail of all layouts and there are scenarios where it's not applicable. The designer and the developer of the webapp should choose the appropriate layout and implement it so that it meets the needs of the target users, delivers the best experience of the product functionality and adapts to the user environment.
I suspect that most web developers go for fixed width because it's by far easier to develop such a site (in addition, many Content Management Systems only offer a fixed-width layout).
Getting a dynamic layout to work well & correctly in different browsers is more tricky - but it is definity doable (I'm just recently working on that issue ;-).
And I do agree with you - I want web pages that dynamically adjust their contents to the browser size that I as the 'customer' like to work with (whether that's small or large). I don't like to be patronized into "not using my browser in full-screen mode" or anything the like...
You might try zooming in. Most modern browsers will zoom the whole page by default, not just the text. This preserves the page layout and uses more of your screen. Usually the shortcut is ctrl + + and ctrl + -. It works well on my laptop, at least
[Forget my mention of the windowmanagement, it wasnt on topic]
I currently run a big internet-community and we'll switch to fixed-width (for 1024px) design asap because we only get problems currently using a dynamic-width-layout: You cant rely on anything, and (the biggest problem imho) text gets to long, so there are only a few lines but the lines themself are much to long to overview.
Readability and Predictability
You need to know how things will be displayed to be sure it will be readable and pleasant to the eyes. By using a fixed width, you know exactly (almost exactly because of cross-browser support) what your users will see.
However fixed-width designs would be a thing from the past if browsers could support correctly exactly 2 CSS properties:
min-width
max-width
That would allow designers to design web sites that would be flexible and predictable. No more surprises and users can use whatever resolution they want.
In my experience, it is for two reasons:
1) Speed - it is generally faster to write a web page in fixed with, rather than trying to write one that resizes correctly at more than a small number of resolutions.
2) The designer of the web site isn't the ultimate approver of what goes into production - if you try to work with a flow instead of fixed layout you get questions about why it looks different on Sallys' PC vs the Big bosses, and why can't you move this over to here, etc, which are easier to fix by moving to a fixed layout.
Tabbed Browsers
Since I use a tabbed browser for day to day use, resizing my window every time I switch tabs is actually a bit of a hassle. I have the window set to the maximum usable width for my purposes, and to accommodate the "largest" tab that is open. For the remaining tabs, having fluid layouts is actually kind of annoying and distracting. Items and text jump around and change position depending on how I may have resized my window for another tab. Also, fluid layouts result in uncomfortably wide blocks of short (vertically) text.
For me, it's a lot easier as a reader to keep my eyes tracking properly on narrower blocks of text with lots of vertical scroll, and it's much easier when sites I'm familiar with stay the same size so that the layout and positioning is predictable, regardless of what I've done to my window to accommodate other tabs. I actually used to be a big fan of fluid layouts, but I find more and more that I prefer fixed layouts now that I use a tabbed browser.
I think the question shouldn't be "Why would you choose a fixed-width design?" it should be "why wouldn't you?"
Firstly, you need to cater for the lowest-common denominator. Many developers will be running on screens with resolutions like 1680x1050, 1920x1200 and 1280x1024. Some users will be using 1024x768, which I personally consider the lowest resolution you need to cater for (thank God it's not 800x600 anymore). If you fix the width to 960-1000 pixels then you don't run the problem of developers unintentionally making pages that can't be viewed without scrolling on a monitor with less than 1600 pixels (wide). Believe me it happens.
Layout on any non-trivial Webpage is hard. Throw in cross-browser support such that your page not only works but looks reasonably consistent and it's a huge problem. Now try to throw in variable width and it just gets that much worse if not impossible. Look at the payoff too: who is it going to benefit? A small minority of users that have high resolutions and actually want to stretch that content across the entire screen. I have a widescreen monitor and I won't maximize my browser for instance. Many people are like me in this respect.
Consider another problem: CSS. CSS s good for many things but is a royal pain in many others. For one thing. Now browser box model differences aside, there are still many quirks with how different browsers handle CSS and even if there weren't there are many trivial things CSS can't do and the only workaround is to do things by pixel.
As a concrete example, I'm doing some tables at the moment that are bursting at the seams. I'm reloading the contents with an Ajax call and replacing the contents. Now I at first tried to fix the widths of the columns with percentages. Doing it this way would be a prerequisite for not fixing the width. Firefox treated those as a suggestion and would resize them anyway even when it arguably didn't have to. I didn't get satisfactory results until I fixed the widths in pixels.
At the end of the day no website really cares if it stretches across 1600 pixels or not. That's what it comes down to.
I've worked with a lot of artists. They design a layout to be pleasing and clear. They want the presentation to match what they designed. Artist-driven design leads to fixed-width. For brochure sites, fixed width makes a lot of sense.
For sites with rapidly-changing content (news or shopping, or most anything driven by a CMS), I much prefer fluid, full-screen designs.
One of the biggest concerns that fixing the width of a website solves is readability. If you let a site be arbitrarily wide and have a block of text using that entire width, it becomes very difficult for people to read. If you make the font size bigger to compensate, then you destroy the experience for people with smaller screens.
On the other hand, if your content is visual or modular and you can make it fill up the page more intelligently, you might have a case for a totally fluid layout.
But I agree with the others who question why you would maximize a browser on such a big display. Why not make your browser window smaller? You'll be more productive and you'll stop worrying about it at the same time.
Many browsers do a better job of scaling websites to be larger than they used to; Firefox 3, at least, grows the entire page when you zoom in, not breaking the layout.
If you want it to take up more screen real estate, use a lower resolution. This can be useful if you're displaying a website on a large monitor up on a wall for public view. Otherwise, take #theomega's advice and use the rest of your screen for other windows.
As for a little (of the very little) of what I know about web design and fixed width sites:
They tend to make good use of white space and draw your focus down the page. Cluttering up the page by cramming every last corner with content is what designers call "visual intimidation." It's difficult to figure out what's important versus what's not.
They feel more "finished", like a picture in a frame instead of like a photo print thumb-tacked up on a cork board.
"It has a resolution of 1920x1200, so all fixed-width sites waste space
The form factor is only 15". So I have to use larger fonts and the text won't fit into these crammed layouts any more, sometimes even getting obstructed by other elements."
There is a good reason for that. If the paragraph are stretched too wide, it gets more difficult to read. Humans need a "break" after about 15 to 20 words and that is EXACTLY why we don't have books that are very wide.
The higher resolution allows you to have MORE details BUT it also depends on HOW you use the space. I never maximize the browser and PC's are built for window multitasking, not ONE window at a time.
The whole point of being able to adjust the size of your browser window is to better see the content of a web page, in the way that suits your situation. If the page isn't going to adjust, why not just make browser windows a single, fixed size?
If I have a big monitor, I want to be able to stretch my window out and have the content correctly fill it. If I need space for another window, I want to be able to shrink my browser window down and have the content correctly adjust by changing the layout (until a certain minimum point, and then by switching to a scroll bar, of course.)
Fixed width layouts are perfectly acceptable.
Fluid layouts are nice, but are more difficult to implement, especially if there are more than two columns and source div order is important.
Line length is an issue regarding readability, but this interacts with font size. So you have to balance width against likely font sizes on screen.
Nowadays, it's reasonable to assume that 1024 x 768 and up is the vast majority of the desktop user market, so you can safely design for 960 px fixed width -- for screen media type.
A couple of important constraints:
ensure is that horizontal scrolling
is never required by the user
if conversions are an issue, make sure
that clickable things -- particularly
"calls to action" or anything than
makes your cash register go
"ka-ching" should not fall to the
right of the 770th pixel or so --
just in case.
But another consideration is handheld media. You should provide alternate CSS for handheld media type. Many of these screens are under 400 px wide.
Delivering a site that looks good and functions on a wide variety browsers, devices, display widths and viewport sizes is a moving target and continuous challenge.
As regards the filmstarts.de site, it is definitely a mess, but the problem is not that it is a fixed width layout, but rather with how the layout is designed and implemented. There are good and bad implementations of fixed width layouts, just like there are good and bad implementations of fluid layouts, or semi-fluid layouts with fixed width elements, etc.
I put it down to laziness. Fixed width layouts are simply easier to design and make look nice because you do not need to worry about the size changing. This, for example, makes it really easy to add images, since you know what size the layout will be.
Personally, fixed-width websites really irritate me. I like to use large monitors. I paid a lot of money for them, so I'd like to make use to make use of them instead of having most of it be left blank. This is made even worse by sites which refuse to get larger if I increase the font size. I don't have the best eyesight and often use larger fonts to read text on websites and nothing is worse than a fixed-width layout leaving me with three words per line and a mostly blank screen...
As far as I'm aware while all the reasons cited are valid, the primary reason is that a lot of machines in monolithic institutions like banks and government orgs are still on fixed and somewhat archaic low resolutions. It's just the lowest common denominator sadly.
I personally like fixed width sites better. I am not forced to mess with my browser window to get a line size I can deal with. I personally find very long lines very hard to read. I also just think it looks better although that is 100% completely subjective.
I have designed and worked with both. Some aspects of variable width sites make displaying data easier. The only problem I have had with them is due to right aligned navigation which was a little messy when it could move based on the user's browser setting.
My final answer - both are fine and each have their place.
I just came across this site, which actually has a link in the top right corner that lets you switch between fixed and fluid.
http://developer.spikesource.com/wiki/index.php/Home
A major point for using fixed width is that the designer can actually control the way the webpage looks irrespective of browser environment. I see two reasons to use FW:
The designer wants the webpage to look all the same.
The designer lacks time/wish/... to test their page in different modes and in different browsers, and just avoids the risk of webpage layot starting flying around.
I didn't make fixed-size layout until I switched to a 32 inches monitor. It is very hard to read the text if the lines goes over 32 inches. I've learned appreciate text that do not span over more than 1,000 pixels, and I have switched to fixed layout since.
But I agree that reducing the content width to < 800px is a pain when you have a big monitor.
Most users lack understanding of how to use a browser properly. When the day come such that users actually know how to use a computer then you will understand that fluid width is the obvious choice for web sites.
I am frequently forced too. None of the 3 developers here has a strong background in design, and the dictated rules and implementations we strive for reflects this. It is an area I want to improve in.
Liquid layout using % as unit can adapt to any screen.
Some layouts must use fixed column design. If there's table or image in the column, you have to use fixed column, or the table or image will break the column in liquid design.
In grid layouts with heights of the grid normally fixed, it's better using fixed column or the widths may got uneven.
It's upto the content of webpage to use elastic column or fixed column layout.
Long lines of text can be difficult to read. For the website I work on we limit the width for usability and readability. We have also designed our site to scale well using CTRL-+ to zoom.

Resources