|
 |
FrogRay <nomail@nomail> wrote:
> I would love some feedback
From an aesthetical point of view, it would be nice if you created at
least some basic CSS file for the pages. It doesn't have to be complicated,
but at least something which would make it look more than raw text. For
inspiration, check http://warp.povusers.org/povtips/ (but please don't
copy my CSS, it's my pet; create your own original ideas :P )
Of course in order to do that properly you'll need to edit your HTML
files so that they contain actual headers etc, not just bolded sentences
as they are now. Also code could use the <pre> tags (with some distinctive
styles specified in the CSS file).
At the beginning you say that the basic syntax to create a heightfield is
height_field{ "MYHF.BMP" }
I think it would be a better idea to tell that the image type should be
specified before the file name right away instead of telling it much later
or else people are going to stumble accross problems
You go to great lengths to explain how to use declared identifiers in
order to center the heightfield regardless of how it's scaled. A slightly
more obvious way would perhaps be worth mentioning:
Translate the heightfield by <-0.5, -0.5, -0.5> *first* and *then* scale
it by whatever you want. It will be automatically centered at origin.
A minor note, but I think it's a bad idea to teach people to use
sky_sphere to create clouds. It doesn't work very well because the cloud
layer above us is *not* centered at our location (like sky_sphere is),
but actually some 6000+ km below us, making it almost a plane instead.
If you want a simple sky, just create a bluish background color and
put the coulds on a plane (with its normal point down). (A bit more
realistic one would have a sky_sphere with a gradient from white at the
horizon to blue above, but that's another story.)
I find it a bit puzzling that this beginner tutorial makes a giant leap
from just telling how a heightfield is created to quite advanced stuff
about trace() (which in fact has nothing to do with heightfields, but
anyways). IMO there would be a lot more important things to know about
heightfields before jumping to such advanced functions. These things
could include, for example, more specific visual examples on the difference
that the input image resolution makes, the difference between smooth and
non-smooth heightfields, how to create heightfields using user-defined
functions, the shadowing and lighting problems inherent to smooth
heightfields (due to smooth triangle problems) with their fixes and
the usefulness of the slope pattern when texturing a heighfield.
The text about "calling trace again" is quite confusing. If you do the
same trace call several times it will, of course, always give the same
result. Apparently what you meant was to call the trace function again
but using the intersection point returned by the previous call as the
new starting point. You don't specify this, though, which may be confusing.
Another confusing thing is that apparently you mean that if the trace
function is called a *third* time using the starting point returned by the
*second* call, then it would not hit the sphere, but once again it's
confusing because it sounds like you are referring to just calling the
trace function a second time (in which case it would simply find the
surface at the other side of the sphere).
The syntax you give for trace() is erroneous.
This sentence is quite confusing: "To put it not-so-simply, you
actually have to check that the length of the normal vector is 0. Do
this using Vlength. This is due to the way POV handles its #if keyword.
If this is too much information, just accept it for now."
What is due to the way POV handles its #if keyword? Why would the way
this keyword is handled affect in any way what is being explained? Why
is this comment even necessary?
And instead of patronizing the reader, why not just give a short
example showing how to detect missed traces? (An example is given in
the next page, separate from this, making this paragraph just needleslly
confusing.)
You have "it's" when it should be "its". Also "desity".
The explanation about what the normal vector is, is quite confusing too.
You tried to make it sound simple, but IMO you only made it sound a lot
more complicated than it is, mixing gravity and whatnot to the soup (the
normal vector just doesn't have anything at all to do with gravity, so
using that as a way of visualizing normal vectors is just going to cause
more confusion than clearing things up).
A simple schematic *image* showing some normal vectors (eg. on the
profile of a heightfield) would have been a lot easier to understand.
Anyways, using trace() and normal vectors just feels like it could
be its own tutorial instead of being given as a relevant part of
heightfields specifically. (Putting trees on a heightfield could be
a good example of the usage of trace() in a trace() tutorial instead
of trace() being given as something related precisely to heightfields
in a heightfield tutorial.)
Btw, if you trace a heightfield (starting from any point above it), it
never fails. Why it is even tested for failure is unclear. (OTOH, all this
should IMO still be a separate trace() tutorial.)
Sorry to be blunt, but this doesn't give too much confidence on the
author's expertise on the subject: "I suspect that point close to the
object of interest will be calculated faster than those far away but
I'm not entirely sure." This shows a rather complete lack of understanding
on how raytracing in general and more specifically raytracing heightfields
works in POV-Ray.
Why would you "translate <Inter.x, Inter.y, Inter.z>" when you can
simply "translate Inter"?
Again, sorry to be blunt, but I think that writing a good tutorial
requires for the writer to know well the subject.
--
- Warp
Post a reply to this message
|
|
|
|
FrogRay wrote:
> Hi Warp,
> Thanks for your suggestions.
> I don't mind you being blunt because you have obviously taken the time to
> read my tutorial thoroughly. When most people come across a not-that-good
> tutorial they simply ignore it, giving the author no chance to improve.
> It's good to know which points are confusing because everything makes sense
> to the person who writes it.
> You've given me lots of ideas to work on so I'll be busy for a while.
> Thanks again for taking the time to write.
>
>
>
>
It is definitely not an easy thing.
My wife is taking an online course in basic HTML. Simple? Try
explaining it to someone who doesn't have even the conceptual framework
to understand the Windows folders metaphor. My wife found herself
flailing helplessly on the first "Hello World" lesson until I threw her
a life line, (metaphorically speaking.) Of course the
intructor/composer of the course studded his lesson with frequent
incantations and admonishments to "Follow the instructions EXACTLY."
But what that really means is: "Follow the instructions EXACTLY, except
for when they are not very EXACT."
Kudos for you for taking Warp's critique to heart, and kudos to Warp, as
you said, for taking the time.
Post a reply to this message
|
|
