POV-Ray : Newsgroups : povray.general : Snail shells : Re: Snail shells Server Time
11 May 2024 16:52:38 EDT (-0400)
  Re: Snail shells  
From: Thomas Fester
Date: 5 Dec 2023 11:35:00
Message: <web.656f500bbeba1b40a206535f8a2a825f@news.povray.org>
"Bald Eagle" <cre### [at] netscapenet> wrote:
> "Thomas Fester" <tfe### [at] scivitde> wrote:
> > Hello everybody,
> >
> > recently I posted a video about snail shells, where I talk about producing
> > images like the one attached. I thought about including my code in the youtube
> > comments section, but there are technical problems. So I am including this code
> > right here. Please tell me, in case there are better forms of distributing such
> > scripts. Also suggestions for improving the readability of my code are
> > welcome...
>
> You _might_ consider posting on github, as this is apparently what many people
> do with their code repositories.
>
> Also, it would be better to post the .pov file as an attachment.
> If you use the web reader, then it's only 1 attachment per post, and you'll have
> to post 2 messages - 1 for the .pov file, and 1 for the rendered image.  If you
> use a news reader like Thunderbird, then you can attach multiple files to a
> single message.
>
> I like your coding style.  Very close to my own, with spacing, etc.
>
> I reformatted your file to use tabbed indentations (Hi, jr!) and added a few
> comments.
>
> Since your purpose will be to write these scenes for educational purposes, let
> me suggest a few things to consider:
>
> 1.  References.
> I almost went off on a huge shell tangent myself, so I know that there are
> several excellent websites and textbooks which cover this topic.  It might be
> good for to include a few references to acknowledge prior work, as well as give
> them some resources to investigate and inspire.
>
> 2. Magic numbers.
> Your spiral parameters are just hard coded numbers, but if they are derived from
> anything, or have some relationship between one another, then it's usually good
> coding practice to try to explain why the values are what they are, or express
> values that are based on prior values as functions of the base value.
>
> 3. Code hierarchy
> Since you're probably coding for people new to either coding or SDL in
> particular, it's always a good idea to keep the instantiation of primitives and
> code-control directives clear and easy to follow.  Everything in SDL terminates
> either with an } or and #end - so there's no way to know what you're ending
> without scrolling back up through the scene - which if the indentation isn't
> clearly demarcated, can be hell to follow (and debug).
>
> 4. Colors
> It looks like your color values are derived from an external color picker, so
> you're dividing by 255.  First, you may want to use the srgb keyword, and
> second, there's a lot more to this simple color conversion than there might
> appear at first glance.  I'll let you search the forums for the fun
> conversations we've had about colors and gamma correction, and srgb.
>
> 5. union {}
> Your shell and your stripes are 2 different objects, which means they will not
> be transformed together.   Just put them in a union.
>
> 6. Versatility
> For many of the morphologies that you're modeling, there are parameters than be
> altered to produce different results.
> You might consider making a macro so that the parameters can be changed easily.
> Then you might make your renders with a variety of parameters to show how easily
> one can produce a wide variety of results with essentially the same code.
>
> 7. Diagrams
> For things like the shells, you might consider adding a small diagram showing
> angles and translations-per-turn, etc.
> The more you add visual pieces that can be used as instructional tools, the more
> your work might be consulted and referenced in other work ---- which gets people
> to consult your work even further.
> The blobs are _excellent_.  What you're doing with blobs/metaballs is really
> great, and more than what I'm usually capable of pulling off.
> That said, you might show where that approach can go wrong - or at least be
> picky in terms of distance and field strength.
> You might also consider using spheres or a mesh or a wireframe to show the basic
> structure - and then show how the blobs melt everything together.
>
> 8. A "Final" render, or a growing add-on scene.
> You have all of these various plants and creatures, but how about placing them
> into a nice scene to show them in context?
> It would be easy enough to make a simple beach scene and start adding modeled
> creature after modeled creature.  So every video gets an addition to a base
> scene.  Model 1 shell, then scatter 500 into the sand.  Model 1 beach grass
> plant, then plant a few hundred on a dune.  Add some radiosity and an HDR light
> probe, and the results can be dramatic.
> Sometime people will put a line of commented code at the top of their scene, to
> provide recommended command-line options for getting the best results for
> certain scenes.
>
> Gotta have some clever and entertaining ways to slip in those "like" and
> "subscribe" requests.  Written in the sand.  The pattern of shells on the beach.
>  An aerial banner or skywriting over the ocean.  A message in a bottle.   Go
> nuts.  ;)
>
> And as always, you can always solicit advice, code, textures, or scene files to
> use in your work.  Maybe throw some POV-Ray logos in there as well to show off
> your favorite script-driven raytracer.
>
> - Bill

Thanks for all this work! It'll take some time...

Thomas


Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.