PDA

View Full Version : VPR-Whatīs next, Improvements and what is lacking?



prometheus
06-17-2012, 09:12 AM
So what is missing in VPR today?

I do have some complaints of things that need to get better, hereīs some short ones, I would like to hear some more suggestions in this thread on what can be improved and what it still lacks.

1. hypervoxels has a very sharp cut in the textures, this is something that we do not see in final native lightwave render, or with fprime or with viper.

2.. lens flares, it doesnīt render behind objects correctly as lightwave final render.

3. fast skin node isnīt compatible..

4. a seperate vpr button of choice, if one would want to navigate in all viewports without screwing their size up and only have a preview window open, but of course if you want to use viewports, that should still be there.

5. the same direct save and replay of previews as viper has, much
faster to get previews done replayed, also preset sizes in window and custom setting of preview size is needed.

7. bloom and glow in VPR, old core platform showed us the bloom at least.

8. better handling of radiosity.(Faster refinement please if possible)

9. paus/ restart of VPR refinement.

Im sure thereīs a lot of materials and shaders still not working, and you are all welcom to contribute what is missing.

Michael

Lewis
06-18-2012, 07:33 AM
10. pan/zoom/reset in VPR window without moving camera/view (ala FPRIME).

Snosrap
06-18-2012, 08:16 PM
Stability. Rule of thumb - don't do anything with VPR up and running. :D

inakito
06-19-2012, 05:19 AM
How about having an option that makes all the objetcs in our scene but the one you are shading, unseen by camera?
Ill so happy with such as simply option...

Ryste3d
06-19-2012, 05:36 AM
- GPU render with SLI support (it is time to take advantage of all the hardware you already have installed)

- Standalone window for second monitor.

Ryste3d
06-19-2012, 05:39 AM
How about having an option that makes all the objetcs in our scene but the one you are shading, unseen by camera?
Ill so happy with such as simply option...

+1 (like f11 but in VPR)

3DGFXStudios
06-19-2012, 05:42 AM
Separate UV window!

prometheus
06-19-2012, 07:27 AM
I agree with all of the above, most the GPU option thou, I think it will be quite faster.

Most of all thou, VPR needīs to render as much as possible as in Native renderer, and with Accuracy, whatīs the point of a previewer if it canīt be used to tweak with accuracy? working with hypervoxels and finding out that it looks completly different when using final renderer isnīt any good.

and how about the skin shader and subsurface materials, it takes so many iterations to tweak and use final renderer instead of having it working with VPR.

Michael

Tobian
06-19-2012, 08:09 AM
3) - use skin, that's compatible, and it's superior too: before skin, none of the skin materials were energy conserving, so mostly they look wrong, unless you manually configure them. The prepass simply can't be done in VPR. If there's no prepass then the look will be different, so that would kill the point of previewing it. The prepass also has an inherent bug for objects outside of the camera's viewport too (but seen in reflected surfaces etc)


otherwise no problems, though I don't see any GPU things coming soon, that would require re-writing the whole shader pipeline to be compatible with Cg or Cuda or the like.

Ryste3d
06-19-2012, 08:25 AM
V-Ray, Octane Render, LuxRender, FurryBall, Blender... they all use it.

Sensei
06-19-2012, 08:35 AM
Stability. Rule of thumb - don't do anything with VPR up and running. :D

I am starting VPR immediately after loading scene..

Tobian
06-19-2012, 08:36 AM
So.. you're describing a bunch of renderers which were built to use the GPU from the ground up... (Vray does not use the GPU 'Vray RT' does) I don't hink any of them can use CPU AND GPU together, except for passes, it's an either or scenario, and in all cases you need some pretty damn beefy GPU's to go against a CPU.

Other applications have integrated modeling and layout in one application too.. I just don't see that coming 'soon' into LW either, and when it does, for some time it will have huge caveats and limitations, while they get all the features in there... much like GPU renderers...

akaracquel
06-19-2012, 09:01 AM
I don't like how it tries to start over (redraw?) if i move or press buttons/settings/windows - which won't directly affect what the render will look like. e.g - select object/camera or moving windows out of the way. It feels like it could go faster (in terms of decreasing the amount of time this adds to the workflow) if it ignored these things and continued to process without restarting.

Sensei
06-19-2012, 09:08 AM
I don't like how it tries to start over (redraw?) if i move or press buttons/settings/windows - which won't directly affect what the render will look like. e.g - select object/camera or moving windows out of the way. It feels like it could go faster if it ignored these things and continued to process without restarting.

Yes, it's total nonsense. Mine previewer never had this issue, because I thought about it since the first day of development, and simply rendering threads were changing RGBA buffer, and there was another previewing thread that was running 10 FPS, and calling OpenGL function glDrawPixels() to transfer RGBA buffer to gfx card (it was taking less than 1% of CPU on Core 2 Duo 2.0 GHz).

With VPR just moving window on top of Layout is causing complete rerendering. I could not believe mine own eyes when I saw it the first time.. But the faster machines are with years, the less annoying it's.

Ryste3d
06-19-2012, 10:01 AM
So.. you're describing a bunch of renderers which were built to use the GPU from the ground up... (Vray does not use the GPU 'Vray RT' does) I don't hink any of them can use CPU AND GPU together, except for passes, it's an either or scenario, and in all cases you need some pretty damn beefy GPU's to go against a CPU.

Other applications have integrated modeling and layout in one application too.. I just don't see that coming 'soon' into LW either, and when it does, for some time it will have huge caveats and limitations, while they get all the features in there... much like GPU renderers...

You are absolutely right, I don’t expect to se anything anytime soon... that ship has sailed.

But when I se this, I want it.

http://www.youtube.com/watch?v=n295AS5uuzE&feature=related

I don’t care how hard or how difficult or how time-consuming it is to make, but for some reason I still want it. Is that wrong?

Sensei
06-19-2012, 10:11 AM
I don’t care how hard or how difficult or how time-consuming it is to make, but for some reason I still want it. Is that wrong?

But you have it- VPR..

What else is showed there than previewing render?

dwburman
06-19-2012, 11:01 AM
5. the same direct save and replay of previews as viper has, much
faster to get previews done replayed, also preset sizes in window and custom setting of preview size is needed.



We currently have the ability to set custom sizes of preview windows when making previews. You just need to set the undock preview option in the display options (if I remember the location properly).

It would be kind of nice to have a separate VPR viewport like Viper (with preview/playback options) that you could move off to a separate monitor and pan/zoom like fprime.

scratch33
06-19-2012, 01:27 PM
Gpu
Dof
Motion blur

Snosrap
06-19-2012, 07:00 PM
I am starting VPR immediately after loading scene.. So do I - but then I do other things and LW crashes. It's very stable if VPR isn't running.

Snosrap
06-19-2012, 07:01 PM
I don't like how it tries to start over (redraw?) if i move or press buttons/settings/windows - which won't directly affect what the render will look like. e.g - select object/camera or moving windows out of the way. It feels like it could go faster (in terms of decreasing the amount of time this adds to the workflow) if it ignored these things and continued to process without restarting.

Yep - good point.

Greenlaw
06-19-2012, 07:46 PM
Being able to toggle VPR off and on using Ctrl f9 is nice but I still rather have a toggle button on the viewport to do this. The current keystroke combo requires two hands (or an awkward reach across the keyboard anyway) so I have to take my hand off the mouse to use it.

Hmm...I just realized I can reassign this key combo. Still want that toggle button though. :p

And, yeah, FPrime-style '2D' panning and zooming is still high on my list of VPR wishes.

G.

Greenlaw
06-19-2012, 07:50 PM
Eh, nevermind. I reassigned VPR Toggle to 'v' and it works fine. :)

G.

Sensei
06-20-2012, 12:53 AM
So do I - but then I do other things and LW crashes.

I don't even remember when the last time I saw crash when VPR was active and me doing something with scene.. Probably in LW v10.x times..

Lewis
06-20-2012, 01:16 AM
But you have it- VPR..

What else is showed there than previewing render?

VERY,very fast GPU preview renderer. Granted on very fast/expensive machine BUT thing is that with LW is that updating GFX card or buying PRO one hardly helps you with anything in openGL/VPR/or performance speed. Very little difference with gamers 200$ card and Pro 2000$ GFX card. If i could get faster VPR with buying 2nd (SLI) or 3rd GFX card I'd buy it or if i could get modeling openGL performance speed boost. Sadly it's not the case with LW :(.

so yeah GPU support would be very welcomed.

Sensei
06-20-2012, 01:19 AM
GPU is completely useless for most of you!

How much memory you have in GFX card 1 GB? 2 GB?

And how big scenes are you making?

Somebody making scenes loadable by 32 bit LightWave could use GPU, it could fit in gfx memory..

geo_n
06-20-2012, 01:24 AM
change refresh issue without the need to turn on transparency in aero. :D
Other than that its better than vray rt out of the box.
Can newtek pause on working on the renderer again for now?

Lewis
06-20-2012, 01:35 AM
GPU is completely useless for most of you!

How much memory you have in GFX card 1 GB? 2 GB?

And how big scenes are you making?


Well if you are going by that route (how heavy some scenes can be) then VPR is completely useless for me too/anyway (in those scenes) 'coz in heavily poly/memory intensive scenes I often make it's faster to hit F9 on smaller resolution than wait for VPR to even start rendering and let alone render something (Lot of lights/GI, arch-viz Interiors where draft mode is useless (cut's bounces/don't look anything close to F9, etc..) and non-draft is slow as snail) :D.

But there is other people who use LW for different tasks like product design/viz and they rendering just few objects in some environment (HDRI/GI/lumi polys) so this would very easily fit into 2GB RAM and render tremendously fast on such GFX card system :).

prometheus
06-20-2012, 01:41 AM
We currently have the ability to set custom sizes of preview windows when making previews. You just need to set the undock preview option in the display options (if I remember the location properly).

It would be kind of nice to have a separate VPR viewport like Viper (with preview/playback options) that you could move off to a separate monitor and pan/zoom like fprime.

Yes I know, I have been giving that advice for people wondering how to set a specific resolution, but my point was that workflow wise, vpr needs improvements in that area, it take to long time to first go to display options, undocking, go down to the animation timeline and set preview options etc.

Viper had it all right, floating window, generate preview instantly, and saving with at least three default resolutions..
(ad a custom resolution box for VPR) this is something that VPR could have too, and a choice to choose a float window or use the Layout viewports, would be way more effective to be able to choose and work in all viewports in wireframe or shade mode and have a float vpr if you want.

But as you mentioned, youre with me on this too.

Regardless of how the code is written today for cpu rendering, I think it will become obsolete if it continuous to use cpu, I believe GPU and cuda will be the future for such things, I hope they could pull something off to work with TurbulenceFD too in rendering, the simulations for GPU of turbulence is way faster on my machine.

Cinema 4d has itīs own previewer for turbulenceFD, not sure if it is GPU thou..Jascha mentioned that VPR wasnīt ideal for tweaking rendering of fluids, and he would look in to a specific previewer for lightwave ..if possible, but I do not know if that could be GPU and cuda supporter or just cpu.

prometheus
06-20-2012, 01:45 AM
GPU is completely useless for most of you!

How much memory you have in GFX card 1 GB? 2 GB?

And how big scenes are you making?

Somebody making scenes loadable by 32 bit LightWave could use GPU, it could fit in gfx memory..


Ehh? what is that? works great for octane, even not lightwave thou, but for lightwave it works much faster to simulate TurbulenceFD and choose GTX 480 rather than my
I7 960 CPU.


I heard from the vfx team behind red tails that Nvidias cuda advances made it possible to acheive so much more iterations of fluid renders when using GPU, perhaps pure BS?

Not gonna start another whining Core debate, at the time Newtek were working on Core and a new lightwave, it was so talked about how they looked in to new hardware for adapting a new code, unfortunatly not much seems to have
been translated to work with cuda technology...yet.
Michael

Sensei
06-20-2012, 01:48 AM
What have particles to do with renderer? Nothing..

But try making simulation of 1 billion particles with GFX card..
Can't you? Out of gfx memory.. ?

Then think what I am talking about..

Sensei
06-20-2012, 01:52 AM
If particle has position, speed, acceleration, color and temperature parameters it's taking 52 bytes at least. 2 GB / 52 B = 42 million particles (without anything like screens in memory).

I counted the all LW particle buffers, and it's taking 132 bytes per particles. So 2 GB / 132 B = 16.6 million.

prometheus
06-20-2012, 02:01 AM
What have particles to do with renderer? Nothing..

But try making simulation of 1 billion particles with GFX card..
Can't you? Out of gfx memory.. ?

Then think what I am talking about..

who and what are you quoting?...particles?..Im lost.

Michael

Sensei
06-20-2012, 02:03 AM
Fluids, fire, cloud, smoke are particles..

You said "TurbulenceFD", not me.

prometheus
06-20-2012, 02:13 AM
Fluids, fire, cloud, smoke are particles..

You said "TurbulenceFD", not me.

Ah..yeah, but please talk about fluids, no need to change description of the discussion even if it technological boils down to particles or voxel grid.

I May be way out of my leauge discussing this tech with you, I can just refer to what I have heard and seen about GPU rendering of fluids, and how much faster turbulenceFD is simulating, but simulation isnīt comparable to the rendering engine we generally are discussing thou.

I just believe that from what Ivé seen it looks like GPU could handle fluids
a lot faster, but it might be that the software for some fluids are written so well and adapted for GPU, wich just as well could have been for CPU too...canīt say for sure.

As far as rendering with GPU, when comparing octane with VPR and even keyshot where octane is the only one using GPU, I have found octane faster than the others, but that might not actually say it is faster, depends on scene and lighting objects and materials etc.

Michael

prometheus
06-20-2012, 02:21 AM
I love the real time fluid demo from Nvidia developers.

http://www.youtube.com/watch?v=WDFNLJeoh6s


http://http.developer.nvidia.com/GPUGems3/gpugems3_ch30.html

Sensei
06-20-2012, 02:34 AM
I love the real time fluid demo from Nvidia developers.


You wouldn't believe how easy it is to write..

3D array of cells with constant positions, box with 64 cells in X, 64 cells in Y, 128 cells in Z, so total 524288 cells.
threads are decreasing life time of cell in every frame. If it's lower or equal to 0.0, cell is empty. Result is fading smoke to void.
"head" is jumping between borders, where it flies, it's adding 100 or other constant to life time of cell. Color and transparency is graphic representation of cell life-time.

rikka+
06-20-2012, 02:44 AM
10. pan/zoom/reset in VPR window without moving camera/view (ala FPRIME).

+1

and undocked vpr window.

A material preset view for setting surfaces, like the sphere panel in vray, could be useful too.

inakito
06-20-2012, 03:44 AM
-1 gpu vpr

prometheus
06-20-2012, 04:00 AM
You wouldn't believe how easy it is to write..

3D array of cells with constant positions, box with 64 cells in X, 64 cells in Y, 128 cells in Z, so total 524288 cells.
threads are decreasing life time of cell in every frame. If it's lower or equal to 0.0, cell is empty. Result is fading smoke to void.
"head" is jumping between borders, where it flies, it's adding 100 or other constant to life time of cell. Color and transparency is graphic representation of cell life-time.

Ah...now it makes perfect sense(i)

Go ahead and write one, one thing that would be great for fluids or inside turbulenceFD, that would be an option to real time tweak adjustments in the turbulence noise settings and scaling,sort of like if you are working with standard native lightwave particles and run the play button while tweaking wind vortexes.

That would mean so much to get what you want while tweaking without having to set the parameters, calculate the sim, go back and redo etc..
Off topic from VPR thou..but nevertheless, It would be great...this could
be implemented first hand on a flat 2d grid most effective, before copying over to 3d voxel grid.

Ps Sensei...join forces with Jasha.

Michael

Ryste3d
06-20-2012, 04:14 AM
But you have it- VPR..

What else is showed there than previewing render?

Yes I have, and here is how it works for me:

http://www.youtube.com/watch?v=aA2KbvmCnOk&feature=youtu.be

GI settings:

Intensity 500
Bounces 3
RPE 800
SBR 24
AT 45
Mini PS 3
Max PS 70
Multiplier 80

win 7
Core i7 3930 3.2Ghz 6 cores (Overcloc 4.1Ghz)
GTX 680 2Gb
32Gb RAM

prometheus
06-20-2012, 04:20 AM
Hereīs another feature lacking from VPR, working with TurbulenceFD fluid plugin.
Case of VPR not being able to handle multiple scattering, final render does, this is due to reasons below appaerently...

"
Re: Multiple scattering in VPR?

Postby jascha ŧ 07 May 2012, 15:34
Right, MS does not work with VPR. That's unfortunately due to the way VPR is built on-top of the old LW architecture, so it won't change until the LW architecture changes.
And yes, constraints like this fuel into the need for a separate TFD previewer/renderer. So that area is likely to get more attention in the future."

Michael

Sensei
06-20-2012, 04:35 AM
Yes I have, and here is how it works for me:


You would have to load this scene in GPU accelerated renderer and use exactly the same settings (which is not possible ;) ) to really see the true speed of GPU version..

In GPU renderers demos they are using cars, or some figures in the center, in completely empty scenes - ray is hitting car body then reflected flying to eternity and hitting environment in the most cases = no surprise it looks fast..
With closed interior scene with many bounces, rays are bouncing until reaching Bounce Limit set in the settings. Draft mode is exactly lowering Bounce Limit.
Completely different environment.

40 sec for full render, should be 10 sec for half resolution in VPR, and approximately 5 sec for Draft mode + half resolution (as long as full render has exactly the same number of pixels as VPR viewport area)

Ryste3d
06-20-2012, 04:58 AM
You would have to load this scene in GPU accelerated renderer and use exactly the same settings (which is not possible ;) ) to really see the true speed of GPU version..

In GPU renderers demos they are using cars, or some figures in the center, in completely empty scenes - ray is hitting car body then reflected flying to eternity and hitting environment in the most cases = no surprise it looks fast..
With closed interior scene with many bounces, rays are bouncing until reaching Bounce Limit set in the settings. Draft mode is exactly lowering Bounce Limit.
Completely different environment.

40 sec for full render, should be 10 sec for half resolution in VPR, and approximately 5 sec for Draft mode + half resolution (as long as full render has exactly the same number of pixels as VPR viewport area)

Thanks for explaning how radiosity works :-)

Here is why I think GPU render is the way to go: 1:32

http://www.youtube.com/watch?feature=player_embedded&v=ZJwdEtKjcM0#!

Sensei
06-20-2012, 05:05 AM
1:50 - he switched viewport mode to OpenGL perspective mode to not destroy whole presentation by trying to navigate with renderer turned on. then after placing camera in right position, switched back to preview :D

CPU renderer/previewer can really do it fast- it just must to store buffers for later use! And smart recreating what was changed.
e.g. user is playing with light A, but there is 10 other lights he was not playing with - VPR will just restart whole rendering- but it should buffer every light result independently and when user played with light A, just regenerate this ONE. And result would be that dual-core CPU immediately would beat any GPU with 6-cores and 2 cpus.. But only while tweaking!
Moving camera causes regeneration of everything (that's why who recorded it, didn't want to show this unpleasant effect ;) )

Lewis
06-20-2012, 05:07 AM
40 sec for full render, should be 10 sec for half resolution in VPR, and approximately 5 sec for Draft mode + half resolution (as long as full render has exactly the same number of pixels as VPR viewport area)

Should be, could be... etc ? But as you can see from his screen recording video it's NOT, it's slow (my experience also with any interior rendering in VPR) and not even remotely same looking as F9 renderer, not even in non-draft mode which is supposed to be "same render engine" :). Let alone unsupported features (yet) as DOF, Mblur, Real Lens cameras etc. etc...

Lewis
06-20-2012, 05:11 AM
1:50 - he switched viewport mode to OpenGL perspective mode to not destroy whole presentation by trying to navigate with renderer turned on. then after placing camera in right position, switched back to preview :D

True BUT it's not joke scene (1.5mil polys and LOT of textures) and after he switched ON GPU renderer again he got full quality in 1-2 sec with all the detailes effects, Bokeh, glow, bloom..., AND as you can see on screen it used only 774MB of ram out of 3GB on videocard, so he has room for PLENTY more of details/polys (so at least 5 mil polys for a 2GB RAM (single chip GPU are limited to 2GB per CPU afair?), try that interactivity/quality with VPR :D.

EDIT: and yeah BTW i also turn off VPR many times when changing camera angle/view 'coz otherwise it's very unresponsive/hard to navigate with anything little more complicated than boxes in non-draf mode ;).

Sensei
06-20-2012, 05:14 AM
Should be, could be... etc ? But as you can see from his screen recording video it's NOT, it's slow (my experience also with any interior rendering in VPR) and not even remotely same looking as F9 renderer, not even in non-draft mode which is supposed to be "same render engine" :). Let alone unsupported features (yet) as DOF, Mblur, Real Lens cameras etc. etc...

If you have different look in VPR than in F9, you should pack scene and send to NewTek in bug report. I am reporting couple such differences in look per week!
e.g. Translucency was not working in VPR when Diffuse was 0.0 (it worked when diffuse was e.g. 0.0001 or higher). I found it, and 2 days later it was fixed.

ps. VPR should be exactly the same renderer as F9, F10. There wouldn't be such problems..

Lewis
06-20-2012, 05:20 AM
ps. VPR should be exactly the same renderer as F9, F10. There wouldn't be such problems..

Of course it should but as we see it's NOT or at least it's cutting corners where it shouldn't and by that making it look very different - darker/less bounces etc.. :). Any proper (with actual windows ;)) Arch-Viz interior GI scene looks different in VPR than F9 and NT knows it for sure, so no need for me to pack 100 different scenes to prove them that - right ?

Sensei
06-20-2012, 05:21 AM
If they would know it, they would fix it..

One simple enough scene showing issue is enough (unless there is more issues).

VPR differences I am reporting they're fixing instantly.

Lewis
06-20-2012, 05:24 AM
If they would know it, they would fix it..


Hehehe yeah right, should i bring up some KNOWN/Reported modeler bugs (with case numbers 3-5 year sold ?) to point you how wrong you are by thinking that or you realize by how silly that "argument" is :)?

Sensei
06-20-2012, 05:27 AM
For instance?

ps. I will resend bug, and next week it will be gone, as long it's easy, not architectural issue..

Lewis
06-20-2012, 05:31 AM
For instance?


Lets say my oldest one in curent Fogbugz system (many others gone down with old BugBot system) is this one - Case 3627 Edge Bevel on Polygon loops - cracking Open 8.3.2007 5:24

geo_n
06-20-2012, 05:31 AM
Holy 999 euro for furryball 3.0.
Octane render was a bargain.

Sensei
06-20-2012, 05:40 AM
Lets say my oldest one in curent Fogbugz system (many others gone down with old BugBot system) is this one - Case 3627 Edge Bevel on Polygon loops - cracking Open 8.3.2007 5:24

Give direct link.. Otherwise nobody can see it..

Lewis
06-20-2012, 05:45 AM
Give direct link.. Otherwise nobody can see it..

NT see it, who else needs to see it ?
Edited, link is at safe hands of Mr. Sensei now ;).

Lightwolf
06-20-2012, 06:04 AM
P.S. this is just one of several so don't think that's only thing left unfixed while reported long ago.
Don't worry... all of your bug reports are visible to anybody now... ;)

Cheers,
Mike

Sensei
06-20-2012, 06:23 AM
NT see it, who else needs to see it ?


OMG. It's not about trust, but reproducing and then writing new one with technical language, where it will be better showed with suggestions and theory "why is it happening" from modeling developer point of view..

I did it already..

Kuzey
06-20-2012, 06:37 AM
OMG. It's not about trust, but reproducing and then writing new one with technical language, where it will be better showed with suggestions and theory "why is it happening" from modeling developer point of view..

I did it already..

Sensei,

Haha...can you do this will all the bug reports?

Newtek..can you hire Sensei to review bug reports and then rewrite them in this "technical language" to make bug fixing easier?

Brilliant stuff,

Kuzey

Sensei
06-20-2012, 06:42 AM
Haha...can you do this will all the bug reports?


I would faster make this tool from scratch than describe issue in English with screen-shots.. :p

Sensei
06-20-2012, 06:46 AM
Newtek:
I can reproduce your issue in the current internal build. This issue has now
been assigned to a developer.

Thank you for your report.

Kuzey
06-20-2012, 06:54 AM
I would faster make this tool from scratch than describe issue in English with screen-shots.. :p

I would not be surprised at all :hey:

A fully updated edge bevel tool would be a dream, along with all the other outdated tools :)

I hope LW12 is the year of Modeler!

Kuzey

Lewis
06-20-2012, 06:57 AM
Newtek:
I can reproduce your issue in the current internal build. This issue has now
been assigned to a developer.

Thank you for your report.

Your point ?

I get that reply for every bug i report, don't mean it's fixed instantly or so (as you can see from my case :)).

Granted it's modeler "turn" so maybe next version will have some long standing bug fixes but then again I need them yesterday or better to say years ago :D.

Also you don't need to be developer to see/explain to DEVs that tool is broken (in this particular case edge bevel) which has several more problems/bugs anyway so new unified bevel (one bevel to rule them all ;)) is necessity anyway.

Sensei
06-20-2012, 07:41 AM
https://fogbugz.newtek.com/default.asp?12887_eq2mgai0

So, how to open this panel? Chuck (me too) don't have idea..

https://fogbugz.newtek.com/default.asp?40855_i4sg5h8be8miupup

Any interactive modeling tool can only modify the Primary Foreground Layer. Background Layers/other Foreground Layers are read-only..

Non-interactive tools (Command Sequence) could in theory set Primary Foreground Layer.

Lewis
06-20-2012, 07:52 AM
https://fogbugz.newtek.com/default.asp?12887_eq2mgai0

So, how to open this panel? Chuck (me too) don't have idea..

Agian, can you explain me your point? You plan to "resubmit" all my bugs now to "explain technically" what's wrong with them or what?

If you (or Chuck for that matter) don't know how to get to this part of program then it must be user error? right :D?

If i tell you how to find it , will you finally admit you are wrong (and stop changing subject sporadically) ? at least sometime :D :)?




Any interactive modeling tool can only modify the Primary Foreground Layer. Background Layers/other Foreground Layers are read-only..

NOT TRUE, For instance Multishift and Bevel (not edge bevel just bevel) works with all selected FG layers just fine and i'm sure i could find few more. Tools i named are just few of many which don't respect that rule = BUG/bad design/whatever, user just expect consistency and same workflow for tools - this is not so it's bug/problem and reported so i don't see problem.



Non-interactive tools (Command Sequence) could in theory set Primary Foreground Layer.

Is that written in manuals as limitation/intended usage of program ? No ?, then it's a BUG, issue , problem, whatever and it needs to be solved regardless of you thinking it's "normal". it's not consistent (some interactive tools work with multiple layers and some don't work) so it's not good or normal or expected behavior..

P.S. Here is fresh screengrab for you from 11.x. BTW it's changed a little in 10.x (to a better three dots :)) but still not proper "load" button as suggested in that report.

Snosrap
06-20-2012, 10:03 PM
I don't even remember when the last time I saw crash when VPR was active and me doing something with scene.. Probably in LW v10.x times..

Of course I can't make VPR crash on command, but replacing objects and replacing images are suspects in my mind.