What I think you are referring is Level of Detail Models (LOD’s). It’s a technique used in games. What it does is reduce the polycount of an object that is far away from the camera. THe further away it is, the lower the polycount becomes. If you move in closer, the model slowly regains it’s detail untill you’re back at your original LOD.
I never noticed to be in the 3dsmax viewport though, what makes you think it does that?
Well anyway, I do wonder if this falls under the viewportFX scope. It’s related to the viewport & performance, but I don’t think it is related to OpenGL, since this sounds like something a CPU could handle.
Anyway I noticed that my knife tool & Create Edge Loop ( CTRL+R) don’t display. The tool itself works, but you do not see those pink cutting lines you normally have.
I used Demohero’s build.
You remind me that a remesh modifier could be used instead. In blocks mode if you like. (a build modifier could be combined too)
If its something very fine like grass a decimate modifier could work as alternative.
Of course turn the modifier off for render time.
The main problem I see with it is that it requires the object to be not instanced/linked if you wish to toggle it on/off in the working scene.
Anyhow this appears to not be very related to viewport rendering/fx after all, instead something similar can be used by a modifier/ script. So Jwilkins (or anyone) feel free to disregard in this context.
Good god yes. The same thing can be said about many operations with multiple objects in blender. This kind of workflow slowdown is everywhere in blender, too. Is there some technical reason why blender handles operations on multiple selected objects so poorly?
Try using maya sometime. Its the absolute worst
i don’t say blender is the only one short here, but it should NOT be ignored, i think it’s a simple function to implement and DOES save tweaking time very much.
Yes, multi object editing really is the Achilles heel in Blender. This is very evident after watching the latest Bullet integration video. In this case, you can multi select objects and copy attributes via the tools panel. Ideally you would be able to do this via the properties panel.
Hopefully this issue will become a higher priority for the Blender Foundation after Mango. I am guessing it is related to the depsgraph re-factor?
True, for now there is the copy attributes addon that helps with some multi object editing. I say some because not all attributes are covered by the addon.
Armature bones aside from octahedral view aren’t displaying properly in Cycles mode nor are they selectable for me (envelope view makes everything go awry similar to problems I see in ACDSee sometimes).
Mesh disappears from view in texture and material view in cycles.
Doing various things (entering rendered view in particular) causes most text to display a bold white outline (makes the file navigator unnavigable).
Node editor is missing its wired connections and sockets in both Blender Internal and Cycles.
All of the above reproducible here from default blend file (adding single armature bone, switching to cycles, toggling w/e, adding cube then assigning default node material)
Windows 64bit r48451 Demohero build
GeForce GTX 260 Windows Vista x64
using out of date drivers for both graphics and CUDA (high enough to run Mersenne 95 and Seti@Home; not enough to clear OpenCL 1.1)
– may try the linux SC (not as recent r-wise as this build)
Edit: I find it somewhat odd that I seem to be the only one seeing these regs. I’d rather not let my issues slow the general process down, as I can always fall back on other OS’s if I see trunk give me similar issues in the future.
Colored wireframes I think it’s very important, it would be madness not doing it, but if it’s a pain and out-of-this-year’s-scope then it’s OK. But eventually the proper thinking is to be implemented to make Blender more productive.
Facts:
Sometimes when you work on enormously dense scenes it’s a pain to navigate, everything simply is pitch black. You have tos select every mesh one by one until you start to understand what’s going on, also if even you give clear names (which is a waste of robust artistic power) into your meshes chances are that you have not photographic memory to remember each object, so again you highlight until you compose the scene in your head out of the blind.
If you work on blueprints then you are bad luck if they are white bg with black lines, it’s a waste of time changing the colors with image processing applications.
Sometimes you need to make helper meshes, to calculate stuff, or prototype shapes (snap to vertex). So in order to understand what it going on you need to think visually and not mentally.
Great news I’m only seeing now :D. Apart from better performance when handling particles and high-poly geometry in edit mode I think an AO preview mode would be very useful when texture painting. Currently when you UV a blank texture to an object you only get a silhouette of that object in the view-port. Having AO preview would eliminate the hassle to bake AO for every single object. If it hasn’t been mentioned before and if I’m not sounding dumb then CUDA support would also be awesome.
blank textures are black generally so that would not work or matter in texture paint mode. AO may be good in sculpt, but a bit expensive…and CUDA would alienate many, many Blender users…and what should we use CUDA for exactly?
Unfortunately no, i have no idea if anyone built a version of Blender with such patch (and the image with colored wireframe i posted is faked, i just colored them manually in an image editing application)
By blank textures I meant white ones. You can’t precisely see where you are painting on the object surface because it’s flat white. With AO multiplied over it you would see much better.
If by AO being “expensive” you mean performance hungry then I suggest you check out martinsh GLSL AO filter.
I don’t think an option for nVidia owners to enable CUDA support for view-port fx in userprefs would alienate Blender users. It’s setup currently this way for Cycles with CPU render being default.
I’m no programming expert and I’m not even sure if this is at all possible with “view-port fx” but by what I’ve seen in games and render engines, CUDA speeds up things significantly.
no, I see you points, and the model visibility makes sense, for me it is not required at all though. I was just under a completely different assumption, but still pushing CUDA code to viewport means additional code to maintain…maybe OpenCL would be better(less splitting hairs), but we are still a way off for that stuff…just my opinion.
i have no idea if anyone built a version of Blender
it was integrated with filicis builds along time ago and the patch is very outdated, if some updates it I’m willing to include it in my builds happily.
I’m just wondering how this project is coming, been a little quiet here this week…and I have a question…
I do a lot of game editing and creating(that is my primary blender use 3d asset creation for games/when I am not coding them ;))
my current project is a doosie with more than 16 mill polygons for the landscape, I have it split into 32X32 chunks(1024 pieces of terrain)…this is a huge task for blender I set the clipping distances so I can see just enough to edit what I want…the two issues are
1)selection lag, we all know about this issue, it can take me up to a minute or more at times to select an object.
2)general performance(high poly count) this I solve with cliping, but I would aslo like to see degradation distance…e.g when things go beyond my clip(or a secondary clip range)set them to the next lower level of draw(either wire or BB)…it would be amazing to be able to set all three ranges where objects withing the first range are fully shaded, second stage flat/wire, third stage BB…I’m not sure if it is in your GSoC scope or not, but never hurt to put it out there.
I remember in a blender-podcast episode campbell explaning how wire mode is rendered in viewport, basically if you want to mix solid and wire, the ‘view’ must be rendered twice and mixed, which would probably make it slower not faster.
but I know what you mean, atleast you see your huge mesh (the part in wiremode).
vs 