Dkendig I got the error information!

[DaveReyes]

Im doing a comercial render its a house, actually this is going to be my render for the contest, It was rendering fine but when I add to my design all the furnitures and vegetation, every time that I started rendering it crash an appear a message that saids

microsoft visual c ++ runtime library: runtime error: c/programafiles/google/google7.exe, this application has request the runtime to terminate it in unusual way please contact the application supports team for more information. Sombody help Pease :-[

[dkendig]

Re: Bug or Not Bug 1.48.89

That error doesn't help. I'm guessing you ran out of memory though. Any idea how much ram was being used during the render process? For additional details, post a copy of our error log:
http://forum.asgvis.com/index.php?topic=7503.0

Be sure to have the error occur, then ensure that SketchUp is closed, THEN open the error log. Every time you run our plugin, the error log is wiped, so be sure that you don't open SketchUp again after the error occurs, or you'll lose the error details.

[DaveReyes]

Re: Bug or Not Bug 1.48.89

=======System Information=========
platform = win32
country = UnitedStates
language = Spanish
====================================
About to make our qapp
after make qapp
Made it after UIManager.initialize
C:\ProgramData\ASGVIS\Python26\Lib\site-packages\Ft\Xml\InputSource.py:346: DeprecationWarning: functions overriding warnings.showwarning() must support the 'line' argument
FtWarning, 2)
FtWarning: Creation of InputSource without a URI
Entering renderArchive
About to start readArchive - C:\ProgramData/ASGVIS/VfS/current_skp.xml
215.042000 seconds is how long it took to read C:\ProgramData/ASGVIS/VfS/current_skp.xml
0.661000 seconds is how long it took us to correct the file paths for all external texture file references in the scene.
(to ensure this process goes as quickly as possible, please be sure all references to external texture files are correct prior to rendering)
87.958000 seconds is how long it took to add the plugins to our renderer

[dkendig]

Re: Bug or Not Bug 1.48.89

no errors in that error log. How about your memory usage? Did you keep an eye on that to see if you got close to 2gb of ram before it crashed? You won't be able to get past 2gb without crashing.

[DaveReyes]

Re: Bug or Not Bug 1.48.89

45.5MB That is what I have in this model I havent even reached 1gb.

[dkendig]

Re: Bug or Not Bug 1.48.89

45mb... how is that possible? A blank scene in SketchUp uses over 100mb of ram... Are you telling me the size of your scene file? or the amount of ram used by the SketchUp process in the task manager?

[DaveReyes]

Re: Bug or Not Bug 1.48.89

45.5 mb the entire model in sketchup. my scene file!

[DaveReyes]

Re: Bug or Not Bug 1.48.89

I am really frustrated, Im losing time here in the office. please help me out. :'( for real man I wanna cry, Im losing my patience.

[DaveReyes]

Re: Bug or Not Bug 1.48.89

=========System Information=========
platform = win32
country = UnitedStates
language = Spanish
====================================
About to make our qapp
after make qapp
Made it after UIManager.initialize
C:\ProgramData\ASGVIS\Python26\Lib\site-packages\Ft\Xml\InputSource.py:346: DeprecationWarning: functions overriding warnings.showwarning() must support the 'line' argument
FtWarning, 2)
FtWarning: Creation of InputSource without a URI
Entering renderArchive
About to start readArchive - C:\ProgramData/ASGVIS/VfS/current_skp.xml
144.134000 seconds is how long it took to read C:\ProgramData/ASGVIS/VfS/current_skp.xml
9.492000 seconds is how long it took us to correct the file paths for all external texture file references in the scene.
(to ensure this process goes as quickly as possible, please be sure all references to external texture files are correct prior to rendering)
Traceback (most recent call last):
File "C:\ProgramData\ASGVIS\Python26\..\VfS\ASGVIS\vray plugin.py", line 215, in add_to_renderer
vray_param = param.to_vray_param(renderer)
File "C:\ProgramData\ASGVIS\Python26\..\VfS\ASGVIS\vray plugin.py", line 92, in to_vray_param
return self.value.to_vray_param(self.name, renderer, final_gamma )
File "C:\ProgramData\ASGVIS\Python26\..\VfS\ASGVIS\vray types.py", line 348, in to_vray_param
return PyVRay.VUtils.DefStringParam(name, self.to_vray(renderer))
TypeError: argument 2 of PyVRay.DefStringParam() has an invalid type

Traceback (most recent call last):
File "C:\ProgramData\ASGVIS\Python26\..\VfS\ASGVIS\vray render.py", line 328, in render
self.addAssetsToRenderer( self )
File "C:\ProgramData\ASGVIS\Python26\..\VfS\ASGVIS\vray render.py", line 102, in addAssetsToRenderer
ref.plugin.add_to_renderer( self )
File "C:\ProgramData\ASGVIS\Python26\..\VfS\ASGVIS\vray plugin.py", line 215, in add_to_renderer
vray_param = param.to_vray_param(renderer)
File "C:\ProgramData\ASGVIS\Python26\..\VfS\ASGVIS\vray plugin.py", line 92, in to_vray_param
return self.value.to_vray_param(self.name, renderer, final_gamma )
File "C:\ProgramData\ASGVIS\Python26\..\VfS\ASGVIS\vray types.py", line 348, in to_vray_param
return PyVRay.VUtils.DefStringParam(name, self.to_vray(renderer))
TypeError: argument 2 of PyVRay.DefStringParam() has an invalid type

Traceback (most recent call last):
File "C:\ProgramData\ASGVIS\Python26\..\VfS\ASGVIS\vray render.py", line 408, in renderArchive
self.render()
File "C:\ProgramData\ASGVIS\Python26\..\VfS\ASGVIS\vray render.py", line 328, in render
self.addAssetsToRenderer( self )
File "C:\ProgramData\ASGVIS\Python26\..\VfS\ASGVIS\vray render.py", line 102, in addAssetsToRenderer
ref.plugin.add_to_renderer( self )
File "C:\ProgramData\ASGVIS\Python26\..\VfS\ASGVIS\vray plugin.py", line 215, in add_to_renderer
vray_param = param.to_vray_param(renderer)
File "C:\ProgramData\ASGVIS\Python26\..\VfS\ASGVIS\vray plugin.py", line 92, in to_vray_param
return self.value.to_vray_param(self.name, renderer, final_gamma )
File "C:\ProgramData\ASGVIS\Python26\..\VfS\ASGVIS\vray types.py", line 348, in to_vray_param
return PyVRay.VUtils.DefStringParam(name, self.to_vray(renderer))
TypeError: argument 2 of PyVRay.DefStringParam() has an invalid type

got to app_quit
Just called cancel render of VRayArchiveRenderer

[dkendig]

Re: Dkendig I got the error information!

DaveReyes - Sorry to hear you're having trouble, I hate to see anyone cry. So it appears that you definitely have an error in this second error log. Looks like it's having trouble with a particular parameter having an invalid type... which is odd to say the least... You're using 1.48.89? If you'd like, I could add you to the beta testing group, and you could try rendering this scene with 1.48.94. I don't know too much else we can really do about that error though. (To skip the part where you say "okay" and I add you a day later, I just took the liberty of adding you to the testing group. If you don't want to try the latest beta, that's fine, just thought I'd throw it out there as an option).

When I was talking about the 2gb limit, I was referring to RAM usage, not the size of the scene file. The size of the scene file is irrelevant for the most part. It can have images embedded in it, which will increase the size of the scene file, but not the resulting RAM usage when trying to render the scene. The error you're getting, doesn't quite seem to match the results you would get if you were having a RAM usage issue, but I have heard that it's hard to get a scene file that is 30mb or larger to render properly sometimes (again, this all depends on whether the file size of the scene is so large due to the embedded textures, or the complexity of the scene). It all depends upon the complexity of the scene, and your render options.

Check this post out for some tips for rendering large scenes (the post is about Rhino, but the same rules apply for the most part). http://forum.asgvis.com/index.php?topic=5887.0

[DaveReyes]

Re: Dkendig I got the error information!

Hello kendig, Alright how can I try the beta version?

[dkendig]

Re: Dkendig I got the error information!

I guess the info about rendering large scenes I sent didn't work out? There's no garauntee that 1.48.94 is going to work any better for you. If the problem is that you're running out of RAM, I know for a fact that it won't work any better. To download the latest beta, just head over to the vray for sketchup beta testing forum and look for the topic "Beta Releases >>ALWAYS THE LATEST<<"

[DaveReyes]

Re: Dkendig I got the error information!

kandig, Im trying to revert to vray 1.05 but I am having a lot of problems, what I should do

[DaveReyes]

Re: Dkendig I got the error information!

Now I am having problems insalling tha 1.05, the new version its not working what Im going to do I am in deadlines here in the office.

[dkendig]

Re: Dkendig I got the error information!

DaveReyes - reverting to 1.05.30 isn't updating to the beta... Information about reverting can be found here: http://forum.asgvis.com/index.php?topic=7764.0 If you want us to look at the scene, post a link on here to the scene, and we'll see what we can find. If it's a commercial project that you don't want to have given out to the public, just send us an email with a link to a place where we can download it so we can look at it.

You still haven't told me how much RAM is being used when you render, so I'm definitely not ruling memory usage out as the cause of the crash. 90% of the crashes reported are from memory usage issues, so I don't know why you're so sure it's not a memory problem... Is it because you have a bunch of RAM in the computer? Perhaps you're not aware that the amount of RAM in your computer is irrelevant? You're limited to less than 2gb of RAM for V-Ray for SketchUp, regardless of how much is actually in your computer. This is mentioned and discussed all over the place on our forum, as well as our frequently asked questions page.

Question:
I'm going to be upgrading my OS, should I get 32-bit or 64-bit?
Answer:
The reason that most people are interested in 64-bit Operating Systems (OS) over 32-Bit systems is the added memory usage that they allow. Memory limits, as well as a number of aspects, should considered in regards to making the choice between 32-bit and 64-bit operating systems. One of the first should be whether your hardware and/or peripheral manufacturers make drivers for the 64-bit OS that you are researching. If a manufacturer does not offer a driver for 64-bit OS, then that may be enough to decide on a 32-bit operating system.

In regards to memory usage, it is important to understand the current memory limits with 32-bit systems and the limits for 32-bit applications on 64-bit systems. With 32-bit systems, the maximum amount of memory that can be use by default is 2 gbs per process. There is an option, referred to as a 3gb Switch, that will allow for your computer to use more memory, equating to 3 gbs of memory available per process. However, the application must be compiled with the Large Address Aware tag in order to utilize the extra gig of memory that the 3gb Switch allows.

With 64-bit systems, you will only programs that are native 64-bit programs will allow for full usage of all of the memory that you have installed on your system. 32-bit programs that are not compiled with the Large Address Aware tag will still only be allowed to use 2 gbs of memory. 32-bit programs that do have the Large Address Aware tag will be able to use up to 4 gbs on a 64-bit operating system.

Currently SketchUp is only available as a 32-bit application and is not a Large Address Aware application which means that the memory usage under 32-bit and 64-bit operating systems will be the same. However, current builds of the DR Spawner are compiled with the Large Address Aware tag and there will most likely be 64-bit versions of the DR Spawner with the next full release of V-Ray for SketchUp.

Currently Rhino 4 is also only available as a 32-bit application, but it is a Large Address Aware application. This will allow for up to 4 gbs of memory usage. The next version of Rhino will have a native 64-bit version available which will allow for usage of all the memory that you have installed on your system. At this point, McNeel is very early in the beta process and there is no release date set for the next version of Rhino.

Memory References
http://msdn.microsoft.com/en-us/libr...px#Differences
3Gb Switch
http://www.microsoft.com/whdc/system...AE/PAEmem.mspx
http://en.wiki.mcneel.com/default.as...ressAware.html

http://software.asgvis.com/index.php...209&Itemid=534


I would also like to mention that if you are trying to take a scene that was made in 1.48.xx, and take it back to 1.05.30... you're going to have a problem. Software from the past, doesn't know what to do with software from the future. You'll likely have to recreate your materials and render settings. The model will be fine, but the rest will need to be done most likely. I'm sorry I haven't been able to respond faster, I'm not a customer support representative, I'm a programmer.