||Aug 2, 2012 01:37 AM
||Jan 6, 2013 09:48 PM
||Feb 20, 2013 07:54 PM
|What Games do you play:
Send Private Message
Wolftacular has contributed to 12 posts out of 469696 total posts
(0.00%) in 2,735 days (0.00 posts per day).
20 Most recent posts:
In my own experience, having more lights means lightmaps take longer rendering
While having more geometry means lightmaps take longer saving
If your map is massive, I'd say that's the reason for the delay. But I might be wrong.
If they used to render fine and now they don't, it's definitely because of the new stuff you added. I've noticed the cyan error usually causes other abnormalities even in different areas of the map. For instance: before I got rid of my cyan errors, there were some solid collide-able walls I was able to shoot through. Funny thing is they were literally almost on the opposite end of the map. Once I got rid of the errors, everything went back to normal.
And I think what Maniac1000 meant was that you could create a custom .sky model with the stuff you want to show outside, but like I said in the OP, this is not a good alternative if your render geometry is right outside or right next to the map. Sky models are only good for far away stuff, in my opinion.
So I'd just recommend the same thing again... Turn whatever render-only geometry you have outside the map into collide-able geometry and seal it.
Save a copy of what you have right now and try what I did; make the materials collide-able and seal them if they're not already sealed. You can still use the +sky material for those faces you didn't have before.
Well, after much trial and error and no pleasing results, I decided to give up on the whole "render-only" approach, and instead, made everything collide-able and simply sealed it all on its own. This works perfectly, though I wish I could've done it the other way since this involved a lot more work and I've heard somewhere that collision geometry takes up more space.
Either way, I guess a good solution is to avoid render-only if it's not 100% inside playable area!
The problem, I'm sure, was that the game thought it was outside of the map since it was completely unreachable and the only collide-able thing around it was the skybox. I don't know how to explain this too well but let's just say the game must've thought it was between walls like ZX 707 said.
Many thank-yous to ZX 707 for his help in the thread
And to altis94 who sent me a .max of one of his maps to help me with what I was trying to accomplish!
Figures. I guess it didn't occur to me since I wasn't even using a skybox, just some faces on the roof rendered as the sky.
Thanks for the quick reply!! Very appreciated!!
So I did what you suggested, ZX 707. All of the geometry is now within a skybox. It helped but not completely! For some reason, some of the surfaces do show up now, but some others don't!! Weird thing is that there doesn't seem to be much of a pattern as to which do show and which don't. What I mean is, there doesn't seem to be a specific area affected; random faces are missing from random spots.
At least some of them are there now. I must be doing something wrong.
1 - Because I didn't have a skybox before, I simply created a big box that completely enclosed the entire map and gave it the +sky material. I made sure to link it to the frame. However, the geometry isn't continuous, if you know what I mean. I don't think it should be a problem since both "shapes" (the map and the box) are sealed and, again, I get no errors besides the clipped-to-no-leaves warnings. If I'm supposed to make everything a single, continuous shape, then can you give me tips at how I should go about it if the map itself is already sealed? You can only look to the outside through the (collide-able) glasses already in place.
2 - When I import the .wrl, the faces it marks seem to be flipped in the error geometry. As in, facing the opposite normals that my geometry actually faces. I don't know if that's how it's supposed to be or if that might hint at something. I'm sure my geometry is facing the correct way, though.
Sorry for the long post! I really appreciate the help!!
Edited by Wolftacular on Dec 30, 2012 at 02:36 PM
I'll try to keep this short, though I usually have a hard time doing so (and you can probably tell by now lol)
I'm making an indoors map. The map has windows to the outside. I know about skyboxes, but I want to place some decorative geometry right outside of some windows (extensions of the same building, etc). I figured I'd set them as render-only .
In tool I get a bunch of "surface clipped to no leaves" warnings, which all point to the geometry outside of the map when I import the wrl. I get absolutely no other errors. When radiosity finishes, I notice everything looks fine and dandy, except that the decorative geometry from outside the map is missing.
Funny thing is, if I grab all this geometry and drag it inside the boundaries of the map, I get no warnings or errors, and it renders... But I need it outside :I
What am I doing wrong? Appreciate the help!! Thanks!
Je suis très désolé sur ma français... Je suis un étudiant
Le problème ne semble pas être que le programme ne peut pas trouver mscorlib, parce que mscorlib est le qu'est donné l'erreur. Cependant, mscorlib EST connexe.
Le que t'ami a dit sur "64bit" est vrai, pour le que je peut regarder. Seulement les ordinateurs avec un 64bit OS ont une "Program Files (x86)" fichier. Vous ont besoin d'essayer le du NET Framework... Essaye telecharger la version plus neuve.
The problem doesn't seem to be that the program can't find mscorlib, since it's mscorlib that's giving the error. However, mscorlib IS related..
What your friend said about "64bit" is true, from what I can see. Only computers with a 64bit OS have a "Program Files (x86)" folder. You should try the NET Framework thing... Try downloading the latest version.
The problem was in the sky tag! The thing I mentioned about "ray length" was kind of off; I wasn't home when I made that reply. Now that I'm on the computer I checked again and the value is called "test distance", and it is under the radiosity sub-category in the lights category of the sky tag. Sounds like a mouthful!
Anyway, the initial value was 50 world units. I doubled it to 100, and now the shadows show up fine! ;u;
Rawr! Now I have to figure out what's up with that weird block on the shadow, but I'll save that for another day. Thanks all!
The french part is cut off, but it says the process can't access the file it is attempting to create, so it could be a privilege thing.
Try running the program with Admin privileges. (Right click on the program, Run as Admin)
EDIT: Since the french part ends in "because it is..." I'm willing to bet the complete sentence is "because it is being used by another process". If the admin privileges thing doesn't work, check to see you don't have the bitmap tag opened elsewhere.
Edited by Wolftacular on Aug 12, 2012 at 12:37 PM
I'm willing to bet the collision model does play a role with the shadow casting since no shadows were rendered when I first made the scenery tag and added no collision geometry to it. Also, I remember once I tried to scale the dragon down a bit, but only changed the gbxmodel tag (didn't re-do collision) and the shadows didn't change (that is, they remained big even though the visual model of the dragon was a lot smaller)
Either way, I've definitely played with the sun position. Notice the results on the one with the dirt ground; how the head cuts off in the shadow. This happens no matter where the sun is placed. I tried raising the skybox by like 5 times and that didn't change anything, though it was a good suggestion.
Playing around with the sky tags made me realize there is some sort of "ray length" option under the lens flare sub-category in sky tags. Could this be related? Maybe I need longer rays for the shadows to reach the bottom.
Something else I'm going to try is add some sort of floating surface in the level geometry in front of the dragon's head and see if the shadows render onto that; might help me narrow down the problem.
Edited by Wolftacular on Aug 12, 2012 at 01:27 AM
I have a little problem, I'll try not to make a TL;DR but probably will anyway
I made a massive dragon for map. REALLY big. The idea was that it would cast a shadow over a good portion of the map. I didn't see any shadows with debug lightmaps, and I figured it was just that (debug lightmaps). So I left it all night running final lightmaps, and there were still no shadows. So I went and made a box map to put my dragon in and see if it was casting shadows. It IS... But only up to a certain height. Basically, the shadow makes it seem as if though its head was cut off. It's not the collision model or anything because I also tried lowering the dragon way into the ground so that only a small part of the neck and its head would show, and when I rendered shadows of that, the head did show (but the body was under the level)
Does anybody have an idea of how to fix this? Or am I better off just including it in the level geometry? Oh, and last question, if you set a surface as render only (so that it doesn't have to comply with sealed world rules) does it still cast shadows?
Your help and expertise will be appreciated!! :D
Here are a couple pics of the shadows. The shadows in the grassy map are from the mountains :(
Edited by Wolftacular on Aug 10, 2012 at 11:18 PM