Oren-Nayar-Blinn material model Blender version.

[thorax]

As it is right now the code goes in and out of a working state very often. Right now it doesnt work. While writing the shadowmap support I accidentaly changed the code so that no meshes are exported.

If you were using Windows, I would probably suggest CS-RCS
as a revision control system.. Its too easy to screw something up, so it should be equally as easy to check stuff in and out. I wonder if there
is equivalents to this in Linux.. I just check-in and check-out the entire
source directory everytime I'm making a massive change the source.
But every now and then I will just duplicate the source directory.
Another cool trick is to take two different pieces of source,
take one and check it in under one name, and the other as the same name, then use the system to vidually diff the two sources (if you do this a lot you would use a program like WinMerge which diffs files and
directory trees). CVS is nice for remote revision control but I have yet to get a version of CVS that is as handy as CS-RCS is on windows. I haven't seen something like CS-RCS on linux. But I'm sure someone has been influenced by it. In Windows I just right-mouse click on the file or directory and click "Check-in", it requests some information of me [what I did], then I hit the submit and its checked in.. I will do this as much as
three times an hour or more. If I want to compare files, I right click on the file or directory, then select "compare revisions", I select one revision and another, then it shows me either a normal diff of the sources or a visual diff (with stuff removed, striked-out in blue, and stuff added in green).

[JA-forreal]

Thanks for the link Jamesk, I would have never found that one out on my own until it became a part of an official Blender release.

[LethalSideParting]

OK, thank you Cessen, my mistake, it's just that whenever I switched on anti-aliasing all my materials (especially images) tend to look smoother, so I just assumed it was part of the anti-aliasing process (especially being concerned with getting rid of 'jaggies' and all...). Don't mind my ignorance

Anyway, whilst we're here, what exactly is this material plugin system that you're working on? Is it like the current plugin system, where external plugins are loaded in as textures, or is it something a lot deeper with a lot more integration into the Blender material system as a whole? Does it take external plugins (ie files like DLLs and SOs) or is it internally based? If this (your blinn lighting model, that is) is the sort of effect that can be achieved using it, then you've definitely got my interest

LethalSideParting

[cessen]

Anyway, whilst we're here, what exactly is this material plugin system that you're working on? Is it like the current plugin system, where external plugins are loaded in as textures, or is it something a lot deeper with a lot more integration into the Blender material system as a whole?

It is going to be a plugin system for material models (or to be more technical and specific, a BRDF plugin system).
Imagine this:
You know the dropdown menu I implimented that allows you to pick between "phong", "blinn", and "toon"? When the plugin system is done, there will be another option called "plugin", which will allow you to select a plugin. Get the picture?

If this (your blinn lighting model, that is) is the sort of effect that can be achieved using it, then you've definitely got my interest

That is exactly what it is going to allow.

Now I just have to figure out how to do it...
Also, don't expect any major developments soon: it's going to take me quite some time. I'm not even sure if I'll have anything significant to show in time for SIGGRAPH this year (although I hope I will).

[dittohead]

kick me in the shins if ths is somewhere in this thread, as i don't want to look around to see if it's there...

will all this be available 2.27?

i will want to use this in my exodus models if x-warrior tells us all to upgrade to 2.27

[cessen]

will all this be available 2.27?

Not the plugin system, no--I'm still working on that. But hopefully the new material models will be (the Blinn and Toon shaders).

[dickie]

i can't seem to get the 3Delight renderer to work...
any thoughts?

windows2k dual-p3 sgi cobalt.

[thorax]

What you are producing is a lighting/shading plugin system for
blender, not a texturing plugin system.. Its important that there
are abstracted layers here otherwise people will come up with plugins like "blinn marble texture plugin" . Which is creative but hardly
useful if you want to combine that witha bump map. I'm assuming you
are keeping the texture/material system that Ton already has in place and are working with the shading type for the surface (which handles
how the surface is lit)?

I had an idea, which can be found under "UV is Passe" topic in
the "News & Chat" section.. If you are dealing with the
texturing system, what I would think is a really nice feature is
to allow another blender scene to be a source of image information
for the texture.

But what I propose in the long run is to abstract
it so that pixels are not used explicitly but implicitly behind a
interface abstraction that only allows for sample color to be
determined at a particular location on the surface. Then in the texturing
system we could have a plugin that samples color from a texture
whose source imagery is another blender scene, then later we can add
vector-graphics as source imagery, and so on without a reliance on
pixels. This would make blender stand out from other 3D apps in that
blender could have resolution independent texture maps. As more
samples are needed of a surface, more samples are requested of
the texture space (its like making another blender scene into a procedural texture).

An example of using this kind of feature, say you want to create a
bump map of breast-plate of armor, but its quicker and easier to
make a flat piece of sheet metal with rivets in it. But this is usually rendered out to a image map (for coloring) and a Z-buffer style B/W image (for bump mapping). What would be better is to use that scene
as a source for coloring and bump mapping without rendering to a
seperate image in a pixel format, making the blender scene with the
sheet metal (just for example) into a procedural texture for the
breast plate.

I'm using the sheet-metal-breastplate as an example of this concept, its
not the concept itself, just an example of a use of the blender scene as source texture imformation. I'm not proposing that you implement this
but that we talk about it and when people come who want to do
something, we can give them this as a another thing that needs to be done.

[cessen]

i can't seem to get the 3Delight renderer to work...
any thoughts?

I have no idea. I have nothing to do with the RenderMan support project.
(By the way: you might want to post this in the rendering forum--after searching the forums to make sure that your problem doesn't already have a known solution.)

What you are producing is a lighting/shading plugin system for blender, not a texturing plugin system..

That is correct. I agree completely with you, by the way, about keeping the distinction between materials and textures. In fact, that is one of my biggest pet-peeves with RenderMan Interface Specification: they don't make that distinction. They just group them both (in addition to a lot of other things) under the 2d concept of "shading".
Rest assured that materials (BRDF's, to be more technical) and textures will remain as two seperate things in Blender. Besides, even if I didn't agree with you, there is already a texture plugin system, so re-implimenting it to be part of the material plugin system would be redundent.

Then in the texturing system we could have a plugin that samples color from a texture whose source imagery is another blender scene, then later we can add vector-graphics as source imagery, and so on without a reliance on pixels.

Using another blender scene as a texture (as you described) would be quite slow. In order to do that, one has to be able to request the color from any screen-space position. And guess what? That's the same as ray-tracing (although, granted, it would single-hit raytracing).

However, using vector graphics for textures is a very good idea--if it weren't for the vast number of "standards" for vector-graphics file formats. Also, using vector graphics as texture-maps would involve writing a vector-graphics renderer into Blender. But the idea is a good one, and it would be a feature worth having.

At the moment, however, I am not dealing with the texturing system (with one exception, which is a birthday present for a friend of mine). Raster-image texture-maps are quite sufficient for now. Perhaps vector-graphic textures could be a feature in Blender 3.0?

[thorax]

Using another blender scene as a texture (as you described) would be quite slow. In order to do that, one has to be able to request the color from any screen-space position. And guess what? That's the same as ray-tracing (although, granted, it would single-hit raytracing).

Vector graphics is a subset of 3D, if you flatten a 3D scene, its
essentially a vector graphic (what do you want to bet that internally
flash is represented in terms of 3D objects, that would be a easy way to handle bisection of vector primitives, using a z-buffer between two
objects). Also you get Z-buffer data directly (very
useful for bump maps).

Think "incremental development"
A first pass at the solution would be to use a
blender scene as a source of image maps, rendering to pixels (how is this differnet from computing a envmap, its not ray-tracing!), that wouldn't be too hard and would reuse features of blender, allow for complex and intricate scenes with complex looking art without the cost of images (for storage and circulation).

Second pass we would eliminate the pixels and carry the eye ray into
the other scene, this wouldn't be the only option, users could use the
old option if its more efficient and effective.

Ray-tracing isn't even ray-tracing. its eye-ray-tracing, its backward,
forward ray-tracing is impossible.. Ray-tracing is uncreative, it renders
shadows dark, it doesn't solve the problem of radiating surfaces (as in radiosity), it doesn't compute acurate refractions (my usual test is rendering a glass with bubbles in it, some if not most ray-tracers will fail on this test).

Most 3D work is done without ray-tracing. The method I
speak of wouldn't need to recompute the direction of the ray when
translated to the alternate scene, that was a play on the concept I had.
Essentially the scene could be pre-rendered and mapped onto the objects, if the resolution is not adequate, it could be increased to the user's needs..

The reason I shy away from vector graphics as a solution and aiming
for the 3D first, is the 3D solution is in front of you.. And Ton already allowed for this in very early versions of blender in the sequence editor,
if you go into sequence editor and hit Shift-A, you will get the option
to add a scene as a clip. This allows you to do test composites of a
scene without pre-rendering the entire animation. This feature
should at least be carried on over into the Image-texture interface.

MAybe since I can now compile blender, I should try to implement this feature.. I guess just duplicate the code from the sequence editor
into the code for the image texture..

[Money_YaY!]

Then please do !
More features are oh so great.
But then we would need hotlinks to . From and inside the animation.

Or is that done in flash ? I do not have flash. So I have no clue.


But the look ,feel and size would do great wonders. ^v^