Update! Blender 2.71 RC2 is ready ...

So this about which view you get when you exit quad view? ‘maximizing’ was a confusing choice of word.

Speaking as a developer, anything that alters or breaks existing functionality is not really an improvement for the end user. Workflows are sacred. :slight_smile:

It does make me wonder if there’s an add-on for Blender which lets you save, manage and recall just 3D view perspectives (position, rotation and FoV) because it seems like that would solve at least part of the UX problem that’s been created here - also, useful to have so you don’t have to drop cameras everywhere to save perspectives.

If nobody knows of one, I might roll up my sleeves and see if I can write it myself.

In every modern software like 3d Studio Max, Maya the word is maximize viewport-if i want to do this in max i place mouse in topview and press Alt+W and voala the window are big, i know how to fix a problem but if you want to have serious software stop changing navigation between version.

dude, just drop this “modern software” crap , please. we have a function in blender that does in fact maximize the current viewport, which is different from what you describe. that has nothing to do with modern or not modern.

You can maximize any editor window type “space_bar shift” or “ctrl+up” but you can’t maximize the individual views of a 3d-view editor window that is in quad view. I don’t think this has ever been possible in Blender, DruBran was right on that.

I think you are confusing maximizing windows with the rules that were used when exiting quad view. I prefer the new exiting rules. in short exiting quad view != maximizing window in Blender.

Grabbed 2.69 and can confirm it’s an exit rule peculiar to quad view - but the distinction between an “exit rule” and a “viewport change” from a UI perspective doesn’t amount to much. A user could definitely switch the view from whatever to Front/Top/Side Orthog then maximise it with the Quad View exit rule (by hovering the mouse over the front/top/side view then exiting).

@raylight75, I sympathise, but if you use your right hand to hit Numpad 7, Numpad 3 or Numpad 1 just after you key Ctrl+Alt+Q with your left, it’s a tiny fraction of a second slower even if you have to hit Numpad 5 to switch from Perspective to Orthographic mode.

I’m not developer but my two cents anyways would be to keep the old exit rules and perhaps instead of camera taking the active camera’s view it takes the last 3d-view camera before going in and out of quad-view. In effect that window could change from “camera” to “user”.

The reason I like the new rule is that is simple to go into front, top, side view but a bit of a PITA to try and get a view or angle that you had prior to going into quad view.

I got 2.71 working as of RC2, but I have a suspicion Cycles smoke doesn’t seem to handle memory right in Win32. It gets about halfway through through render ok and then computer suddenly freezes/crashes. (Probably using memory that should be reserved for system?)

Might even be a bug specific to integrated graphics (using chipset on motherboard) that doesn’t have dedicated VRAM. (Had another problem in an older Blender version when texture painting because of that. In that case default graphics setting for mipmaps had to be turned off, or memory addresses would loopback and make textures glitchy.)

Later today I’ll try a smaller size render of a smoke sim (less tiles than the size rendered when crashing) and see if it gets through without crashing. You’d think memory would free up after old tiles complete, but if that’s some aspect of the bug a smaller render working would make that clear. Right?

I checked and RC of Blender 2.71 had mipmaps on. Turning those off seems to get a crash-free smoke render. But some more tests later to see if that’s the case.

32 bit version of system can use only 4 gigs of ram.

Hi, guys, this is not a UI discussion thread.
Only news and questions, please.
@Kramon, XP 32 can only use 1.5 GB Ram for an application and max. 3 GB.
Windows XP is not officially supported anymore.

Cheers, mib

Recent test I ran task manager to watch performance. Most memory was used by system processes. About 3gigs of RAM was mostly free. (Test only has Suzanne, domain, and two lights.)

I think I narrowed it down to mipmaps. (They don’t work with ATI integrated graphics afaik. At least the older Radeon HD series.) But why that affects smoke rendering?

Hi pauljs75_, may it is a Real bug for 32 Bit systems.
Can you please share the file?
May others with 32 Bit systems can test it.

Cheers, mib

mib2berlin: It’s a really simple test… But to not clog this update(s) topic, I’ll start a new topic for it in the troubleshooting forum.

Is anyone else noticing refresh issues with the particle system using this build?

I setup an object based particle system and have them all born on frame #1. They have a life of my entire animation. I have done this before and it works fine. But in this build when I setup my particle system even though I want them born on frame #1 they do no appear until I play through the entire cache from 1-250. Slowy, on at a time, they build up as the timeline plays.

It is like the particle system is ignoring the start frame and just assume the default of 200 frames.

Initial orientation seems to be broken as well. With the Rotation checkbox active none of the settings make any change in a Newtonian system.

Size and Random Size seem to work so I can see that the particle system is responding…

Regression in Cycles Voronoi texture? 2.70 had some difference between color and factor outputs that was useful. It was possible to take advantage of it for good edge definition between cells. Worked great for things like cracked earth or irregular stonework. From what I can tell, it’s not there in 2.71 RC2.

I thought this patch was addressing the problems (reflection darkening at glancing angles) with the cycles anisotropic shader. Was I dreaming? Again? :slight_smile:

That patch made it in after the cutoff. It’ll be in for 2.72

Got a screenshot?

I have to agree with raylight75: They basically broke the functionality of quad view to fix one issue. It’s great to use a number pad for those who have one, but I don’t have one nor do I plan on getting one. I have an iMac and use the Mac keyboard which doesn’t have a number pad. Most laptops don’t have a number pad either. Relying on a number pad where most modern machines that users will most likely use (usually a laptops since they outsell Desktop machines and are now powerful enough for graphics work) is not a well thought out plan imo. Sure we can change the shortcuts but the point of quad view to me is to get an overview of your scene then dive into whatever view you need to do editing. This worked great in previous versions. The issue with perspective being reset was an issue but that was one issues that needed to be addressed. Breaking the whole thing to fix one issue makes no sense.

it’s exactly that i wanted to say, but i have no nerve for discussion especially for small changes in navigation. Thanks