I hope you will. It's not much fun to redo what others already did.

A further reference is
Dan B. Goldman: Fake Fur Rendering. Siggraph '97

> I was intending to write my patch so as to be compatible with this one
> (i.e. the same scene file can be made to use the other one just by
> changing a single parameter) but looking at the syntax this patch uses
> we seem to have completely different ideas about how it should work.

The syntax of my patch was mainly driven by the internal data structures,
which generally is a bad approach. However, be warned that the syntax is
not the main problem of adding fur to povray.

My experience while messing around was:
1. Povray is a huge program. So, it's difficult to to find the right places
to plug in your code. (The Pov-Team does not like to incorporate other
people's patches, because they usually fail to find the right places.)
2. Raytracing realistic fur is slow. This usually makes it fairly hard to
create a nice scene.

> My project will go forward as planned; I may decide to run off a few
> simple pictures using this patch for comparative purposes in the
> 'evaluation' stage, but I will not even be looking at the code.

As you base your work on the same papers, some ideas of our approaches
should be similar. It might therefore be a good idea to look at my code
to see, where you can do a better job and where you can "borrow" some
details.

Finally, I want to advise you to try to get something working as fast as
possible. Special features like curly hairs, forces, or bleeching can wait
until you have a basis for your thesis.

Personaly, I would go for Perlin's approach, because it is the most general
one, but that's up to you.

Greetings
Thomas

Post a reply to this message

> > My project will go forward as planned; I may decide to run off a few
> > simple pictures using this patch for comparative purposes in the
> > 'evaluation' stage, but I will not even be looking at the code.
> As you base your work on the same papers, some ideas of our approaches
> should be similar. It might therefore be a good idea to look at my
> code to see, where you can do a better job and where you can "borrow"
> some details.
Reading your quote of my post, I realise it sounded rude. I will not be
avoiding looking at your code because I don't think it'll be worthwhile,
but because I want to be able to definitely know that I wrote the patch
myself. If I look at your code it will be much harder to convince the
examiners that I have done a sufficient amount of work.

As for the way of specifying it in the SDL, I was thinking of something
easier for the user: instead of requiring an object to fill with fur
like a media, I was going to have it be an extra block in the object
like "texture", so you could say something along the lines of:
torus {
	15,2
	pigment {colour White}
	super {
		fur {
			method 1
			length 1
			curliness 2
			texture { /* see below */ }
		}
	}
}
where "see below" is some way of specifying a texture that varies over
(u,v,w) space or (w,x,y,z) space, so you can have, say, a leopard print
at the base of each hair with a tiny bit of silver at the tip. Having a
fur be a separate block inside hyper allows (a) more than one fur to be
specified, so it's easy to have guard hairs like in real life, and (b)
future expansion with different types of texture e.g. trees on a far-off
hillside as Kajiya and Kay suggest.

> Finally, I want to advise you to try to get something working as fast
> as possible. Special features like curly hairs, forces, or bleeching
> can wait until you have a basis for your thesis.
Yes, the structure of the project proposal tends to be along the lines
of having a main project, which is something that will definitely work
and can easily be done in the time available, and a set of extensions,
like forces and curliness, that are the stuff I want to do. The idea is
that if I do all of what I was originally intending to do, it will look
more impressive because I have done the main project and n extensions.

> Personaly, I would go for Perlin's approach, because it is the most
> general one, but that's up to you.
Personally I would go for Kajiya and Kay's approach, for exactly the
same reason. There are lots of things that hypertextures can do that
they don't need to do for this, and this generality slows it down.
However, with the texel implementation I can fix lots of the parameters
in the same way that they calculate the normal and tangent to the hair
instead of letting them be specified, thus gaining lots of speed.
However, I like the noisy projection function that Perlin uses, and I
think that if I can find some mathematical way to optimise that for the
case of hairs that are usually going to be almost parallel then the
thing will go like a dream.

Thank you for your support. I have managed to convince someone to be my
supervisor and that this is a plausible idea; in October I will need to
convince my Overseers (who are responsible for accepting the proposal)
that it is not only plausible but that it is enough work to count as a
project, in terms of what it will teach me about CompSci. Then next June
I will need to convince the examiners that it worked and that I did much
better than anyone could have expected. I will create a few scenes with
your patch for comparative purposes, and will probably do the same with
RenderMan and whichever Maya plugin it is they use in the films.

Daniel

-- 
A most peculiar man    With the windows closed      And Mrs Reardon says
He died last Saturday  So he'd never wake up  He has a brother somewhere
He turned on the gas   To his silent world   Who should be notified soon
And he went to sleep   And his tiny room    .oO( http://sad.istic.org/ )

Post a reply to this message