POV-Ray : Newsgroups : povray.general : Debugging tools and code optimization Server Time
29 Mar 2024 09:33:39 EDT (-0400)
  Debugging tools and code optimization (Message 1 to 1 of 1)  
From: Bald Eagle
Subject: Debugging tools and code optimization
Date: 5 Sep 2017 10:20:00
Message: <web.59aeb2683872cd6c437ac910@news.povray.org>
I'm starting a new thread to move any further discussion over here, and not
further hijack Kenneth's thread over at

http://news.povray.org/povray.newusers/thread/%3Cweb.59ad8cfca4b127e95cafe28e0%40news.povray.org%3E/


With regard to the discussion on computationally expensive square roots, I
mentioned that I continually come across this advice, the following from an
article written in 2014:

"1. How much computation does your current collision routine take? Do you have a
square root hidden away in there (ie, a distance check)? Are you doing a
granular collision check (pixel vs pixel, triangle vs triangle, etc)? One common
technique is to perform a rough, coarse check for collision before testing for a
granular collision check. You can give your objects an enclosing bounding
rectangle or bounding sphere and test for intersection with these before testing
against a granular check which may involve a lot more math and computation time.

Use a "distance squared" check for comparing distance between objects to avoid
using the square root method. Square root calculation typically uses the
newtonian method of approximation and can be computationally expensive."


I'll have to look around to see what situation the look-up tables were designed
to address.

Apparently conditional statements are computationally expensive as well.

It would be nice to see exactly/approximately how much time each of these types
of statements / calculations takes.

(Some sort of #timer () directive that returns an internal clock duration after
some intializing directive could be useful.)


I was watching some coding videos (Dan Shiff's Coding Challenge) and it struck
me during the circle-packing challenge how fast Processing can access image
pixels, whereas when I try to read in pixel values for an image using
eval_pigment(), it is SLOW.
https://www.youtube.com/watch?v=QHEQuoIKgNE
(~ 25:50)

It would be nice to be able to very quickly populate an array with image data
using an internal pov-ray function.

Look at how fast an image map can be parsed.
Look at how fast a heightfield can be parsed.
But reading the rgb values from an image file can take

FOR

EV

ER.......


Post a reply to this message

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