-
Posts
2,579 -
Joined
-
Last visited
-
Days Won
1
ypoissant last won the day on November 28 2015
ypoissant had the most liked content!
Previous Fields
-
Interests
All things related to rendering. Physically based rendering and materials. Interactive rate bidirectional path tracing.
-
A:M version
old version
-
Hardware Platform
Windows
-
System Description
Win 7 Ultimate, i7,3.2GHz, 6GB, GT-630.
-
Self Assessment: Animation Skill
Familiar
-
Self Assessment: Modeling Skill
Knowledgeable
-
Self Assessment: Rigging Skill
Familiar
-
Programmer
Yes
-
Contests Won
*
Profile Information
-
Name
Yves Poissant
-
Location
Québec city, Québec, Canada
Recent Profile Visitors
2,187 profile views
ypoissant's Achievements
Master (8/10)
1
Reputation
-
From the shadows, mainly from the observation of how it falls on the right armpit. the light placement may have a much larger impact on overall appearance than expected. For me, if the lighting is not setup exactly the same it makes it impossible to draw definitive conclusions. Any form of GI will dramatically soften the surface curves. Apart from that, the gamma correction, as pointed by Robert, is also a major factor.
-
Having good textures plays just a small role in creating good materials. For example, if you take the default material and slap a good wood texture, you will get a plastic with a wood texture. Textures only describe the spatial distribution of the reflectance of the material. The other material properties such as diffuse, specularity, etc., help describe the directional distribution of the reflectance. If you want to avoid the plastic look, you need to experiment with those other properties. Chiccory and Coffee did not use radiosity.
-
From the results I saw on ompf forum, No. The bottleneck is not so much the power of the GPU but the bandwidth between the CPU and the GPU. People who have attempted a "mixed" implementation all came to the same conclusion: You don't gain any speed unless everything is run on the GPU. Note that I have no experience implementing a path tracer on the GPU. All I know are from the ompf forum discussions, blog entries and technical articles.
-
It isn't intrinsically faster than the current Photon Mapping. However, it is a much simpler rendering algorithm so it is often implemented on the GPU. But in order to be efficiently hardware accelerated, a lot more than just the renderer must be ported to GPU. This basically amount to an almost complete re-write of the application. This would be a huge undertaking. I also think that most users wouldn't use such a renderer because of the longer render time.
-
Reflectance is used in two contexts: Used alone, it just means the color or texture. Used in "Bidirectional Reflectance Distribution Function" or BRDF it means the color and the scattering pattern. In A:M, "Reflectivity" refers to the color of the reflection and "Specularity" refers to the width of the specular highlight which is determined by the scattering pattern. So this is not too far from the actual thing. Technically, though, a "Specular" surface is a perfectly smooth surface and "Reflectivity" usually refers to the reflectance of a perfectly smooth surface.
-
Yes. You are right. The hardest part is getting used to a different material representation. Lighting techniques need to be adapted too because the indirect lighting takes care of a lot of additional lights that are typically added to scenes in traditional CG scenes. Modeling techniques are the same. Indeed, physically-based material definition is usually easier to setup. Not only there are less parameters to tweak but the parameters are more meaningful and intuitive. The expected render result is very predictable. There are basically two material setups: One for single layer raw material and one for double layer coated materials. Once this is setup. all that is left to do is change the color/reflectance maps and the layers roughness. Add bump/normal maps where appropriate. It becomes very intuitive very quickly. Once a material is setup. it can be reused on any model and in any lighting situations. Because it is physically-based, it will always look the same no matter the environment it is in and the lighting conditions. The material just reacts to light as it would in real conditions. Yes. Absolutely. BTW, reflectance is a big word but it is just a regular color map with gamma correction removed.
-
Models are fine. No need to convert to polygons. Lights are usable too as their units could be converted easily. It is really about the materials. If you really want to know the details, hold on. I like to distinguish material definitions used in CG world by two categories: "Physically-Based" and "Effect-Based". Physically-Based Describe materials by their physical structure and composition. Essentially using material properties that can (or could) be measured from real-world materials. A material is described by its layers, each layer being described by its reflectance, index of refraction (IOR), absorption/extinction, density. scattering/roughness, emission properties. Typically, providing the reflectance/IOR and roughness for each layer is enough for most materials. Natural materials are single layers composed of raw wood, metal, minerals, etc. Synthetic materials are usually double layer. A based wood material with a varnish coating for example. Paint or a plastic are double layers too because the substrate is a transparent layer in which are suspended colored particles or pigments. Knowing the composition and the physical properties, we can model how light is being reflected off a material. When a "photon" hits a physically-based material, we can compute the probability of it being reflected or absorbed and if reflected, the probability of the direction it will be reflected to. Effect-Based Describe material by an accumulation of visual effects. Diffuse, specularity/shininess/glossyness, reflectivity, ambience are all visual effects. Each of those visual effects have a color and an intensity. Given an assemblage of those visual effects with their properties, it is impossible to infer the physical properties that would produce the resulting material appearance. At best, one of those effects may be probabilistically selected when a photon is being scattered which would constraint the material into being at least physically-plausible. But this does not make the material physically-probable, meaning that even though the physically-plausible material respects all physical laws, the resulting material is very unlikely to exist in nature. And this produces more noise in the final render thus requiring much longer render times. It is possible to describe a physically-plausible and probable material with effect-based properties. But this requires an expertise in actual material composition, an expertise in the actual implementation of each effects for the material representation in the 3D application of choice, and a good dose of math. BTW, this is another difficulty one is faced when using Radiosity/Photon-Mapping in A:M. For best results, materials need to be setup in a physically-plausible way and doing this is not trivial. Effect-based material descriptions are intrinsically full of contradictions: The ambience property assumes the environment is reflected by a perfectly rough material while the reflectivity property assumes the environment is reflected by a perfectly smooth material. The diffuse property assumes light is reflected by a perfectly rough material while the specularity/shininess/glossyness assumes light is reflected by a more or less rough material. In a physically-based renderer, there is no distinction between light and the environment Everything is a source for illuminance either directly or indirectly. But the ambience and reflectivity specify how the environment is reflected while diffuse and specularity/shininess/glossiness specify how light sources are reflected. All the effects properties can make much more sense (less contradictory) if materials are assumed to be double layer (a base material with a transparent coating) but there are no properties that indicates how to separate the properties between the base layer and the coating layer. Such a "separation" property would be impossible to implement anyway. Those are the main differences.
-
I know a lot of people implementing IMS BPT renderers as a hobby, myself included. Personally, my pet project has been in development on and off (but mostly off) for 5 years. While it is a BPT, it is mostly an experimental project where I can test ideas concerning parallelism, concurrency and vectorization in a path tracer context. At work, I maintain and improve the renderer (see attached example). This takes all my programming time. When I get back home, I'm usually not in a mood to keep focusing on programming again. I have played with the idea of porting my pet path tracer to A:M a few times already. But there are a few difficulties. First, this could not be ported as a plugin. It would need to be integrated in the code base. Then there is the material and light issue. Material definitions and light definitions need to be physically-based in order for a path tracer to work. This basically requires the implementation of a separate physically-based material system in A:M. I know from experience that this would not be appreciated. I'm not talking about the A:M community in particular but in general. There is a surprisingly strong resistance to adopting physically-based material definitions in traditional CG circles. People have invested a lot of time learning how to get materials they like in their legacy 3D application of choice and don't like to have to change that. And material in A:M can become quite complex especially when procedurals are used. It is possible to constraint A:M material definition so they are physically-plausible. But this gives unexpected results in renders because although the material are physically plausible they are still generally physically improbable so they don't look like real world materials. And it usually does not match the regular render results either. Bottom line: This would be a large project. Anyone wanting to "hire" an implementer should post an offer on the ompf forum. There you can find computer graphics students (and also professionals) interested in path tracing of all sort.
-
Radiosity is not an alternative to A:M's light. It uses them to compute a global illumination solution. So yes, it is known as "Global Illumination" in other apps. The word "Radiosity" is misleading as it refers to an old, not-used-anymore very limited global illumination technique. This name was kept because it was already used in old days where A:M had an implementation of the "Radiosity" technique. The Global Illumination Technique implemented in A:M is called "Photon Mapping". It is a good technique but is a little bit difficult to use due to the numerous parameters that need to be set just right. "Multiple Importance Sampled Bidirectional Path Tracing" (IMS BPT) is the currently preferred Global Illumination technique and it has no parameters. You just let it render until the render is subjectively noise free enough. Indeed "Photon Mapping" is not too suitable for animation because it produces moving noise in the animation. This can be solved by cranking all parameters to their highest values, thus increasing render time by doing so. But then IMS BPT also requires much longer render time when frames are rendered for animation.
-
Since radiosity seems to be essential for your project, before you invest a lot of time learning either animation or radiosity one after the other sequentially, I recommend you setup a very simple animation, say a moving cube inside a room, setup radiosity in this room and render a few seconds of animation. Just to get a feeling of the time required to render a frame of radiosity and the radiosity effect in an animated sequence. In general radiosity for animation requires quite expensive settings, which translates into long render times because of the required indirect illumination consistency between frames. Radiosity is nice but there is a price to pay. Maybe you will then opt for a non-radiosity render but with well thought out materials and lighting. This "plastic" look you mention is not intrinsic to A:M renderer. It is the result of poorly setup materials. Radiosity will add indirect illumination to your renders but it will not improve a poorly designed material. If your material are designed like plastic, then they will look like plastic without or with radiosity. With radiosity. it will look like plastic but with additional indirect illumination. Designing good material is an art in itself. And designing materials for rasiosity render is even more of an art. You might want to add this into your list of skills to learn.
-
Fantastic result. Your attention to details, both for geometries, materials and lighting, is admirable.
-
Man this new forum system is so Internet Explorer unfriendly. So I'll write that a second time: Consider JavaScript. It runs of all platform, It is a powerful language (much more powerful than it looks at first) that can be used to build large applications. And it is a fun and interactive experience developing and debugging applications in it. You have access to a large choice of libraries and frameworks. I've really been impressed by the open source cinder. See the variety of high class stuff that was made with cinder. And in GoingNative 2013, Herb Sutter challenged programmers at the conference (go to 1h:1min) to come up with a game or something creative that they could program in a few hours to an afternoon. See the results here and here (starting at 8min). Almost all the programmers never heard of Cinder before. So there you have a good feeling of the variety of things that can be done with cinder. It is not too difficult to imagine what could be done by a small team of programmers in a few months of work. It is just a pity that it does not run on portable devices. But OpenFramework, also open source, looks like cinder and runs on all platforms including iOS and Android.
-
A:M code style is very standard object oriented C++. I would not qualify it as "unique". What is unique about A:M code, apart from the obvious use of patches, is the thought that went into the user interface and the unification of operations.
-
One aspect I've been observing in the 3D industries is the switch to Physically-based rendering, The movie industry have been the first to push in that direction. I'd say, the last five years correlates very well. During the last 2-3 years, it is the game industry that is pushing toward physically-based rendering pipelines. The most pitched advantages of physically-based rendering is reduced costs, the artist friendliness, reduced reliance on post-prod. SIGGRAPH have dedicated full day tutorials on this topic for the last 2 years and those tutorials, including presentation from the big players in those indiustries, are available on the Web.
-
I'm not sure where all this hair splitting is leading us in term of differences between splines/patches and Sub-D.