ArtPearl opened this issue on Apr 30, 2009 · 76 posts
chippwalters posted Sat, 02 May 2009 at 2:44 AM
OK, Let's take a look at these bugs one by one.
Quote - 1.Populate with objects which have the material 'volume shaded fuzz' causes crash 1233706551 Fixed
- Eco's cleared randomly on unrelated 'undo' 1233114584 Fixed
- Cloud settings (hide) not saved. 1235275127 Fixed
- Render disappears after interrupt 1235768443 Fixed
All fixed by e-on for you. Good for them. Good for you.
Quote - 5.Revert to instances: 1232902464
I can convert eco instances to objects and manipulate them. I should be able to revert back to instances, as I could in v6i, but this option disappered from the popup menue. I reported this on 01/25, more than 3 months ago. I was told on 01/27 that “This issue has been fixed and will be available in a future update.” It wasnt yet. Now I was told 'it was fixed but wont be available till final release.” Why? when would that be? isnt 3 months long enough to wait for something supposedly fixed already?
Sounds like a real bug. I don't know much about this one as I've actually never had the case to use this feature. What exactly are you trying to do? Perhaps I can help with a work around in the meantime.
> Quote - 6.Saving vob, clicking OK before thumbnail completed render causes crash 1235436940 (& 1233538976 &1233853492, took me a bit to figure out what causes the crashes) ) Still crashed on 4/27 -crash report 1240856555.
Not a bug in the latest Vue Pioneer -> Complete on my systems (all PCs). Can't vouch for Macs. If you need a wordaround, let me know and I can suggest a sure fire way to keep from crashing ;-)
> Quote - 7.Dislexia, Characters/digits typed in the wrong order: 1233423397
When I use a numeric/character fields (rather than slides/gizmo etc) the digits or characters I type in appear in the wrong order. E.g. I type in 91 it appears as 19. (I am absolutely a 100% sure it isnt me who is typing it in the wrong order). The responses I got were “As we releaes updates, we continue to work on the Mac interface.” and “The developers are aware of the issue and are working on it. ”
Certainly not a problem on PC Pioneer thru Complete. I can see why this can be frustrating. I suspect it has to do with something called 'focus' for the field you are typing into. I might suggest as a interim solution typing more slowly between the first and second digit in a field. Though frankly I'm not at all familiar with this bug.
Quote - 8.Drop/smart drop (right/left click) 1233526410
Sometimes when I click for regular drop it executes a smart drop. E-on(and some mac users on this forum) claim they cant reproduce it, but if the developers are any good they should still have a clue were to look for an intermitent bug, that still occurs for me.
If you can't provide a reliable recipe then there's an excellent chance not only can they not produce it, but I suspect they'll instead focus on those bugs they know how to find. I might suggest you try the command-key sequence or menu item and see if it still misperforms. If not, then there's your workaround.
Quote - 9.Number overflow displayed(on render) -1233424438 & 1236646691
I get a huge number(19 digits) in the field that usually shows the number of objects/lights.The responses I got ranged from “ This indeed seems to be a display glitch, which shouldn't affect anything in your scene” to “This is a representation of the zoom feature.” (not true, it is not the same field, the zoom field is fine).
I have seen this one on occasion, but I don't remember how I got there. In anycase, for me, this is not a huge issue as I typically watch the resource level more than polygons. I seem to remember Walther mentioning something about that number is now tied to OpenGL polys and not scene polys. This one's certainly not a show stopper.
Quote - 10.Missing features – scale render, size in real units 1235082940
A. There is no 'display true object dimensions' in the size section of the world browser.
The displayed units in the size section appear to be the internal units, not the real world units.
The manual of v6inf says "The Show actual object sizes ( ) is a toggle button that will display the real size of the object when selected (otherwise, internal dimensions will be displayed instead – usually not very useful, but provided for compatibility with previous versions)." I can understand if you dont want to keep this toggle, but if you admit yourself that the internal units are useless, why did you leave those units rather than the real units - meters yards etc.?
Having the size displayed in real world units and the ability to enter these values numerically are of extreme importance to me. It has implications in many instances. just as an example - if I use the new water, deciding on the value for average depth of foam depends on the size (and position) of the object. It just makes no sense otherwise.
I dont know if v7inf displays real world units for the size, but it would make no sense to have that as a feature available only to pros. EVERYONE needs sensible and consistent units.
Internal units have been with Vue since early on. In fact, only in the recent versions of Infinite have real units also been supported. Internal units are extremely important for many functions, including Python scripts and proper image mapping. I'm sure you are aware of the conversion factors. If not, they are very easy to figure out, just go into the Preferences, change the display units to your preferred one, then object's centers are shown in correct display units (in, feet, meters, etc.). You can do the math if you like. While not a bug, I suspect this should be implemented soon.
Quote - B Resizing a rendered image. In vue 6 inf, on the top of the render- display/screen, the first 2 buttons are + and - for zooming in and out. These dont exist in the v7complete version. I did not see this mentioned in the comparison chart. It is not a problem I cant overcome - if it is a final image I read it into an image viewing/editing program and I can change the size there. However I use it a lot for viewing trial renders. Those are usually small (for quicker renders) and I enlarge them to see more details, even if the quality isnt good. It seriously disturbs my work flaw.
Certainly not a show stopper.
Quote - 11. No undo after align: 1235275732
I use the align command (left bar) to align two objects. I try an undo (edit command, top menu) the align isnt listed as the last command. The operation listed for the undo is the operation before the align.
(and to make matters worse, there isnt even a cancel)
I appears you're just using this control incorrectly. You can click on any of the radio buttons to see in the 4 views what the alignment choice will do. If you don't like it, just click the 'none' radio button on the bottom of the column for the alignment you previous clicked on. This will effectively 'UNDO' your changes and all will go back to normal. You can use the close box on the upper right of the palette to close it.
Just like other programs, there are a number of things which can't be 'undone' in this program. Try saving a vob, then undoing-- you can't. The same is true for MS Word-- you can't save a program then undo. Different programs implement different levels of undo. I believe Vue satisfies the need for preview and undo in the palette on this one. Of course, they could implement another level of undo, but IMO it is no big deal.
Quote - 12. Glowing water: 1237859408
I opened a new (default) scene. Added a box and put the camera inside. The little render preview window shows a black rectangle as there is no light source in the box. I added a water plane. Now I can see in the render preview a light blue surface as though there is a light source. If I edit the water material (not the foam layer), in the transparency tab the 'fading out' and 'turn reflective with angle' are set to 30. If I turn the 'fading out' to 0 , it looks like the light source disappeared and the preview window is completely black again. Doesnt that mean that the water turns luminous(glowing?) not only reflective?Note - This only happens if the 'auto exposure' is on. However it does not happen for other objects instead of the water plane. For example if I have the ground plane above the wtaer plane the scene is completely black whether or not 'auto exposure' is on or off.
There are a couple of issues of concern with this bug report. First, the geometry you are creating is a constructive solid geometry (CSG) box with zero wall thickness, pretty much an impossible rendering exercise from the start. Those who render closed interiors are aware radiosity effects need wall thickness in order to render correctly.
Secondly, you need to understand what auto-exposure does. It's a leveling algorithm applied to maximize the contrast and overall level a histogram of the image. This has the effect of 'correcting' poor lighting in renders, which is good for newcomers as lighting is one of the harder things to master in any 3d app.
Sometimes, it provides a very nice addition to the render. Other times it makes no sense of a render. As others have stated earlier, a person may find working without this feature turned on will make them better at lighting scenes. I know I rarely use it. ArtPearl, if you can describe the type of picture you're looking for, I can probably provide you a scene file which demonstrates best how to set it up.
I understand you say you have multiple agendas for posting your bug list. My answers are based on my desire to either provide workarounds, or point out misconceptions. I hope those who read your posts continue further to see what some of us have to say about workarounds and the relative severity of the above bugs.
My own view, is that you certainly have a couple bugs above which may make things a bit more difficult-- but I personally didn't see one show stopper. Furthermore, for anyone else reading this far, I find if you really want a bug fixed, provide a dead simple recipe for displaying it (Mostly ArtPearl did this). Also, be aware most bug databases have priorities assigned to bugs like:
crash, block, major, minor, tweak, suggestion, feature.
If you consistently submit 'minor' or 'tweak' category bugs, you may find they don't get fixed as fast as those which are crash or blocker bugs. Also, if an existing workaround is known, the bugs priority might not be as high.