[Thomas An.]

TRACKING STOPPED (JUL-01-2005) for Rhinoll v0.6.0
Link to next --> (Rhinoll beta 0.6.1 bug report)
_________________________________________________

CRITICAL:

• None

AVERAGE:

• A01. City names are not sorted alphabetically
• A02. "Assignation of material" text is cluttering the command line buffer for large files with hundreds of materials
• A03. The scene name is allowed to be left blank - As a result it creates filenames such as: ".mxs" and ".jpg" (".tga"). The user should be forced to enter a scene name. Also see related wish item W02, (link))
• A04. The option 'Render only channels' should cause the option 'Open Maxwell display' to automatically clear (The same with 'write mxs only' )
• A05. Bad Sun behaviour.. see post in Bug forum: (link) (oldbug. Not sure if this is Rhinoll specific or Maxwell related)
• A06. Copying from one Rhino instance and pasting to another Rhino instance will cause the render options of the second to be lost and replaced with those of the first. It will also (occasionally) cause the lens length to jump to something unusual (eg from 50mm to 7mm).
  -UPDATE for A06: The lens-length jumping is a Rhino bug, not Rhinoll. (See Newgroup link)
• A07. Bump coefficient of the materials should range from -999 to +999
• A08. Reflection map is not working properly causing metals to render black. Plastics seem ok
• A09. Assigning materials to block instances not supported.
• A10. Use of Match material is not supported.
• A11 (NO FAULT). Phantom materials remain in memory. After deleting an object the material is not dereferenced and the command line mentions "assignation of materials" for objects that are no longer there.

  If you create 3000 boxes and assing them materials, then remove the boxes, all the data of your old boxes remains in the scene due to the rhino undo mechanism; rhino needs all this data in order to be able to undo the last command. When you save the scene the "erased" materials aren't copied to the 3dm file. Rhinoll only use the not "erased" materials. (Pablo Gimenez, Jun/28/2005)

• A12. The default film width and height (36mm, 24mm) will produce a render that is a mismatch with the Rhino Viewport. When the film width and height are 24mm, 24mm the result is correct.
  
• A13. When Rhinoll becomes the current renderer then the "Render" tab in Rhino options should be replaced with the Rhinoll "Maxwell" options tree. If this is not possible for some reason, then a suggestion is to clean out the options in that "Render" tab to avoid user confusion... or possibly migrate the Rhinoll "About" information to that tab.
  
• A14(PARTIALLY SOLVED). (This bug persists for large scenes with over 1000 objects / materials). Materials not saved reliably in the file. I have several instances where re-openning a model has some materials simply forgotten.
  • Method to repeat the problem:
    
  • Draw a box, assign a diffuse material (e.g green)
    
  • Use the "array" command (Rhino) and make 55x55 = 3025 copies
    
  • Draw a ground plane and emitter plane and render (for a few seconds)
    
  • Delete all boxes except the one on the lower left corner
    
  • Use the "array" command (Rhino) and make another 55x55 = 3025 copies
    
  • Select all objects and give them a different diffuse color (e.g. red)
    
  • Render (a few seconds) and stop, save file and close
    
  • Reopen the file --> notice some materials are lost
• A15. Assigning the same bitmap to more than one object, the message "Maxwell warning: Bitmap Already Exists" shows in the Rhino command line after hitting render (actually it's buried in there during Assignation routine). It still renders fine and doesn't impact anything at all, it's just disconcerting to see error messages.
• A16. The longitude/latitude data are not in a D.d form.
  http://jwocky.gsfc.nasa.gov/teacher/latlonarchive.html

SOLVED
Issues solved from previous Rhinoll version:

• S01 (SOLVED). Attempting to render a scene after assignement of matierials cause a rhino crash with runtime error. See also: http://www.maxwellrender.com/forum/viewtopic.php?t=3585
• S02 (SOLVED). The bounce and Low-Quality controls are now redundant in view of Mxl beta 1.2
• S03 (SOLVED). Sky dome intensity allows to set negative value (error box appears but dialog closes)
• S04 (SOLVED). SM disallows to enter negative values (this is bad, our timezones HAVE negative timezones too)
• S05 (SOLVED). Hour accepts values more than 24, day the same - error box appears, but dialog closes and value is set eg. to 40 (in day/hour input box)
• S06 (SOLVED). Material assignment to more selected objects (or groups of objects) causes Material Error bug

HISTORY
Links to previous bug reports

Link to Rhinoll wish-list:
http://www.maxwellrender.com/forum/viewtopic.php?t=3821

[vectornormal]

I get a run time error as soon as I hit the render icon, whether there is a material or not. I've reinstalled twice to make certain installation was correct but to no avail.

Norman

[Stephen]

I get a run time error as soon as I hit the render icon, whether there is a material or not. I've reinstalled twice to make certain installation was correct but to no avail.

Norman

I only get the runtime error if I'm applying materials. Are you sure there's no materials? Maybe you are using an emitter? I think that is treated like a material.
I'm just using the skydome and no materials. The good news, it seems much faster than it did before when rendering without materials.

[jeje]

plus the 0.6 (0.5.9 it says) rhinoll doesn't write mxi file

[dudrjs79]

ya.same here. i was excited about new version but, when i assign material, 'RUN TIME ERRORS' pops up.
render time is little faster. 10 hours > 7 hours.
i think maxwell for rhino looks desparate.

[vectornormal]

I tried again with a new file, added primitives and hit the render button and it did begin to render. I used an exsisting scene and apparently didn't clear everything. New file with new objects and no materials does render for me.

Norman

[Thomas An.]

I tried a new file too, but got the runtime error.

[Siegfried Kircheis]

I tried a new file too, but got the runtime error.

Me too.

[Thomas An.]

plus the 0.6 (0.5.9 it says)

That is interesting... the Rhinoll online documentation (the doc folder after unzipping Rhinoll) mentions version beta 0.6.

It is possible that we were meant to get 0.6 but the developer didn't get the chance to finish the code before the deadline.

[Thomas An.]

- Maxwell renders files created with previous version of rhinoll/maxwell, but all materials are lost, except for dielectrics which seem to keep their properties.

It is expected for the new WIP not to always be compatible with older ones. At least maybe the plugin should be clever enough to check the file and see if it was created with a compatible version and should issue a warning, instead of ungracefully loosing stuff or crashing.

- Sunlight is still a mystery to me. Where is north supposed to be? There doesn't seem to have been any changes on alpha version.

Well north is supposed to be on the Y-axis, but we never know these days. In any case Oscar mentioned sometime ago that there would be some sort of orientation indicator.

[Eric Lagman]

Well I am using the new plug, and things seem to be working better. I had an emitter material assigned to a layer, and it was not lighting my scene. As soon as I delete the materail from the layer and apply directly to object it works.

[Thomas An.]

Has anyone seen this one yet?

Maxwell Error: Invalid monitorGamma value

This occured only on a scene with previously applied materials. Tried applying a new material to all objects and then deleting it in an attempt to start with a clean slate, but no luck.

The new beta definately seems to be working better otherwise. A new scene or scene with no previous materials applied seems to work fine.

Yes, I saw it a couple of times when opening an old scene. It looks like all numerical entries had boggus values like: -2.23345e-05

I don't think it happens if you start from a clean slate.

[Micha]

Bug: Missing camera blade control.

[Thomas An.]

Bug: Missing camera blade control.

Did you see the wish list

[Micha]

Yes, after I post it here. Good idea, I hope the NL team read it.

PS: For me, it is more as only a wish.