Neon needs to be able to refine with out recalculate


#1

I allways set Neon to stop at say 20 iterations (depends on the scene) so the CPU doesn’t calculate more than it needs to.
But sometimes I want to raise that value, and then I expect Neon to just continue to refine, but it needs to recalculate from the start. Could this be changed?

Same goes for setting the value lower, I see no real need to start calcuating the view again, if that is the only change made.


(Andrew le Bihan) #2

That’s the way it works at the moment. Once you get to the end, we kill the renderer to save some memory. The continuation data is lost.


#3

OK, that makes sense, and I like the “at the moment” bit.


#4

So what would be an appropriate interval of time to leave the renderer around in a state ready to continue if it pauses due to a user iteration limit? In other words, how long would the user need to study the result and determine if the image needs more?


#5

To understand your question I need to know why you think time a relevant factor.


#6

I was just thinking that since Andy thought up to now that it would be a good idea to kill the renderer to save memory, perhaps a way to address your concern would be to have it standby for some period of time waiting to see if the user wanted to improve the image before killing it. I wondered how long would be appropriate.

Of course Andy might have something completely different and much better in mind.


#7

Ok, thanks for clarifying, well, time is a flexible thing, like today I sat Neon to calculate 20 iterations for a complex outdoor scene, and went for a coffe, or maybe I needed to do something at the store, so when ever I came back it would be a pain in the butt if Neon had just figured out I had waited long enough for it to kill the data.

To me it would make sense if Neon went into IDLE once it hit the target iteration, and then only killed the data if I started a Rhino command other than changing the Neon settings.

So not time based, but rater command or workflow based.


#8

Makes a lot of sense. But are we talking Neon? I thought it was a realtime renderer and for my small models on my new Xeon machine, it is.


#9

The more useful question would be, is the memory saved worth not being able to(and I guess this is the only thing this feature would enable) add more passes without restarting. For myself I’d say “eh why not?” though actually adding passes has been pretty rare.


#10

True. And the only reason for adding passes is because the passes was sat too low. Either because I was on a laptop and wanted it to run silently and/or to save battery, or because I was on the workstation and was working on a complex model and needed the extra cpu power for other stuff.


(Wim Dekeyser) #11

I feel myself going back and forward on this one…
Yesterday I was about to chime in and say that I really enjoy that feature in Maxwell where I can just continue a rendering two weeks from now if my end user has decided on which view is worth persuing.

But then again, that is a rendering engine; not a ‘display mode’.

The thing with Neon is that it is in the fuzzy borderline between the two. For me, on a laptop and working with heavy models, using it as a display mode is not really an option. I need to put it at another display mode, tweek the view, and then let it render with Neon. Neon’s output is good enough / very good for finals and as such I could just put the passes at 500 - and never need to add passes.

But, as James says, what would it take to save the Neon data so that it could be reused (in terms of disk space / memory). I suppose I could run into a situation where I have found the view I want and then all of a sudden have to work on something else. Then I could resume the rendering in the evening when the PC is not used…

Also, I see that I have saved quite a few models with a viewport in Neon mode and when I later open these, it take me a while to figure out why the model doesn’t appear to be loading. It’s just Neon that is firing up the display that is taking a long time. If the Neon info was saved with the file (disk space cost?), that wouldn’t be an issue…