|
|
Op 24-9-2021 om 00:03 schreef Samuel B.:
> Thomas de Groot <tho### [at] degrootorg> wrote:
>> Op 22/09/2021 om 02:47 schreef Samuel B.:
>>> Hey, a fellow i5 owner :) I've got a 6500 here. It's a really good chip.
>>>
>> <grin> I have an i5 8250 and an i7 8750 here. For some arcane and
>> absolutely trivial reasons, I am using the i5 more than the i7, but
>> there it is. :-)
>
> Based on user benchmarks, the i5-6500 seems to perform a bit better than the
> i5-8250(U), but the i7-8750(H) outperforms both. (The number of cores, however,
> do factor into all this.)
>
Indeed. the i5 has 4 cores / 8 logical processors (hence my +wt7) and
the i7 has 6 cores / 12 logical processors, where I generally use +wt10
or +wt11.
> From what I've seen, CPU performance has been rather incremental over the years
> when it comes to the hard stuff like raytracing... Certain things will always be
> slow to parse and/or render, which is why I try to find faster ways of doing
> things when possible...
>
I sometimes take up again old scenes which I found almost impossible to
render within a "acceptable"(?) time back then, and which now render
pretty fast.
>>> Ten minutes of parsing seems a little steep.(...) Thirty minutes of
>>> render time doesn't seem as terrible as it could be
>>>
>> Not sure as I have not been monitoring closely what is going on, I guess
>> it is the building of the individual mesh2 hairs which sums up. In a
>> next run , I shall save/read the hair meshes and that goes faster in the
>> end imo.
>
> What's the shape of the hair follicles? If they are round, how many sides do
> they have?
>
Using Robert's settings here, without change:
#declare Upoints = 50; // Number of points along
#declare Vpoints = 5; // Number of points around
> And if you're using includes, then perhaps they are the reason for your high
> parse times. So if it's at all possible, maybe try copying all the necessary
> macros &/ functions into your scene file, since using includes in any heavy way
> is much slower than referencing local code. (But I think you knew this already.)
>
Yes, I generally try to put all relevant, repeating, macros and
functions in the scene file. I probably could gain more parse time by
picking out Sweepspline.inc and more especially meshmaker.inc, but I
didn't do that (laziness).
>> But, not trivial, I had the laptop battery in "best battery
>> life" mode; "best performance" mode is certainly faster indeed.
>
> I've got a 2012 laptop, and I've been using it without its battery for a number
> of years now. (The battery's fine, but I like to extend its life by not using it
> ;D) The laptop just stays plugged in with high performance mode enabled at all
> times. Enabling best/high performance really does make a difference.
>
Yes, I increasingly do that too, especially when doing heavy duty renders.
> An unfortunate thing happened recently... I've got the laptop perched on two
> small planks (for air flow) on top of my desktop computer. It's up high so that
> the laptop can get a better signal. Well, one night I was a little careless and
> didn't notice the planks were slipping... Anyway, the laptop fell off and I put
> it back thinking nothing of it. But the next day I realized the earbuds jack was
> askew... Turns out the port got bent when everything fell over, and now it only
> transmits a signal through one channel D: And I can't observe the contacts
> without taking the whole thing apart (I've opened the laptop plenty of times,
> but never removed /everything/). My only other option is cutting a hole through
> the plastic over the problematic area. but at least the thing is still
> functional in all other respects :P
>
Yeah... one of those "stupid" accidents. I got my touchpad blocked
(something heavy fell on it - not my hammer - and since then it is
unoperable) but as I much prefer a good mouse I just leave it at that.
>>> Did I ever post my experiments with hair? I was using an .obj-to-.pov converter
>>> and trying to grow hair from a mesh. The way I had it set up was if a triangle
>>> was too small it only had a small chance to grow a hair, otherwise it would try
>>> to grow a certain number of hairs for a given triangle's area. (...)
>>>
>> I don't remember, but that looks interesting, especially the approach
>> using triangle sizes. I had not thought of that aspect. I simply used a
>> simple trace() function on the skullcap from randomly generated points
>> on an external sphere. Pretty fast by itself.
>
> The code for the hair still exists somewhere, but it is not readily available. I
> do, however, have at hand the program I wrote to convert .obj files to
> POV-readable data. (I may have posted it once; I'll have to check.) The program
> exports arrays, with options for additional data such as neighboring faces and
> vertices. (If you remember some preliminary stuff I posted a while back for an
> IRTC competition, that's what I was using to make flagstones/stone walls out of
> blobs.)
>
I didn't check yet, but I may have that somewhere in my database, filed
under "Sam Benge" :-)
>>> P.S. Thanks for reminding me of Wallace and Gromit. It's a great series. Just
>>> watched A Close Shave. What a gem of a flick :D
>>>
>> Oh yes, I love them. I was reminded of the scene showing Wallace tasting
>> a piece of Moon (on toast) and musing: "Wensleydale?"
>
> Lol. Based on how often he mentions that particular cheese, I'd say it's his
> favorite :)
>
> After you originally mentioned W&G I got to thinking... There might have a way
> to make a convincing clay material, complete with fingerprints. It involves the
> use of slope patterns and projected normals...
>
Now, that might be interesting indeed. Based on blobs I presume?
--
Thomas
Post a reply to this message
|
|