That is less true in the west for now I think; I see enough difference in phones to recognize the different brands from a distance; however in China, it seems that all 'local' brands (most of which you never heard of) are all just making identically looking phones, mostly mirrored after the iPhone 6+/7+. With some interesting exceptions, I cannot really see the difference even from closer up with, outwardly, the same materials, same buttons in the same locations etc. It becomes even harder to see when people have a case around their phone.
Not sure if it is fundamentally a bad thing; it'll push prices down and manufacturers who want to distinguish will try other forms. Like I said before, and some here seem to agree, please experiment with more battery, focusing less on the size or speed. At the electronics fair in Hong Kong last week a friend gave me a tablet which is so cheap that if you drop it you wouldn't even pick it up but just get a new one (his words, not mine) and it is fast enough for me to browse, play some games, chat and have fine battery life. More battery life for this that kind of thing matters to me personally more than screen size/resolution or speed as the latter is more than enough for most people anyway but at the same time people complain mostly about battery life.
I just use Brother Laser printers -- Ink Jet is just a brutally bad way of printing. The multi-function printers are ultra reliable and cheap to operate.
That's exactly right. It's just a general term nowadays for embedding pre-computed information into an asset for the purposes of optimizing the rendering of that asset. Of course, you need a renderer capable of understanding how to make use of this information to properly reconstruct the scene, hence standardization like the Alembic format is useful.
Correct. In this context it means turning the geometry into frame by frame mesh data so that your animation isn't dependent on anything like bones, cloth simulation, muscle/skin simulation, soft or rigid body dynamics, inverse kinematics in the rig, expressions on the bones of the rig etc.
Not only does it break dependencies, but it is also easier to get that geometry into another part of the pipeline like effects, lighting and even compositing.
Neither, and both. Lets say you have a scene with a cup of coffee spilling onto a desk...
The overall description of the scene, where the desk is, the lights and materials etc, could be stored in a USD scene.
Some tool would read this and generate an intermediate file in RIB format. This would be what a RenderMan renderer actually reads.
For the fluid sim itself, the generated RIB file might contain a reference to a plugin which points to the baked Alembic data, which would be a directory with one alembic file per-frame of mesh data representing the fluid surface.
The basic answer is it uses neither file format but what it does use has similar attributes to both.
RenderMan uses RIB files for its scene description and RIB files contain geometry. This means that one RIB file would typically contain a frame of data and source the shaders and textures from separate file paths.
baking, in this context is a stream of vertices where each frame carries geometry information and nothing else.
If geometry wasn't baked in, then you would have a separate description of geometry (and everything else) as well as keyframes which are left to the client to interpolate.
Think of it as a HTML versus a screenshot. Both carry the same information, but for screenshot you don't need anything else apart from image viewer. For HTML you need parser, layout, render, whatever.. poor analogy, but hey.
> Could you explain what "baking" means in computer graphics?
It means that the code/configuration used to produce a particular result (e.g. an animation sequence) isn't accessible anymore, but the result is.
For example, Houdini (http://www.sidefx.com) lets you procedurally animate 3D geometry, using a collection of nodes, scripts, etc. This is very useful for authoring, but is extremely heavy when all you want to do is render the resulting animation.
So, you "bake" the animation to a file (Alembic is a popular option today, which Houdini supports) and then you use the baked file during your rendering. None of the code and computation that produced the animation need to be available to the renderer.
Put another way: "baking" is the CG term for "memoizing" the result of a computational process.
An animated scene is broken down into frames. In each frame there is usually geometry that is moving. Each piece of geometry is a collection of polygonal data that has (xyz) points as its basic primitive.
It is often convenient, sometimes necessary to store point data into an off-line file for each frame of the animation. That point data is called a bake.or a point cache.
For instance if you do a simulation that takes 4 hours to solve you would absolutely want to bake out each frame of the point geometry. Then you can load that data into ram and play back the simulation inside of a modeling/animation program in real time.
We do WebGL, WebVR, CUDA, JavaScript and Node.js and lots of advanced stuff. We service dozens of service-based clients, and 250,000 individual users. We are rapidly growing.
We also contribute to lots of open source libraries including Three.JS.
Really nice work compared to what I consider to be the quite bad Brotli -- an incredibly slow compression standard that only ended up in browsers because it was created by Google.
Curious what your issue is with it -- it basically says "if you dont sue us, we wont sue you". Thats about as good as I can expect from a large tech company these days with regards to patents.
If Facebook wanted zstd in the browsers, which would make sense for them to be able to reduce bandwidth and improve performance, the patent grant seems to make that impossible: Google would never put zstd in Chrome with such a clause.
I don't understand these things well. But if true this would be really bad. LZ4 is everywhere because it was completely free and I think most of Zstandard's real work was pre-facebook by just Yann alone. Now to have its hand tied because of his job at facebook is the worst thing possible.
I just read the Opus patent summary. It seems like if zstd followed the same license using it wouldn't give facebook any license but if I sue facebook I loose the licese to use zstd. Am I correct in that.
Well, I suppose so, provided that you hold patents and want to use them offensively.
Because as far as I can see, Facebook has an exception saying that if they for some reason patent-sue you first, you would be allowed to countersue without losing your license to their patents.
That could be a misinterpretation, I suppose. But if it's right, then Facebook's license seems superior for those parties who wish to end software patents.
Facebook's license seems superior for those parties who wish to end software patents
It's mostly superior for Facebook. If you're a party that wants to end software patents, but intends to use zstd in any place you might want to interface with a company that doesn't hold the same position, then you're screwed.
If you want to end software patents, and Facebook sues with one (not applying to zstd), you're also still screwed. This is relevant because even if you're against software patents, you can take them out defensively. But this license makes that useless.
Compare to GPL vs LGPL, or how the free software codecs all eventually moved to BSD.
