-
Posts
28,206 -
Joined
-
Last visited
-
Days Won
394
Content Type
Profiles
Forums
Events
Everything posted by robcat2075
-
An app that searched an A:M Chor for any and all keyframes could make a list their times, eliminate the duplicates, and present that list to you, to be pasted into the custom frame range. That would be possible with the "string" tools that most languages have.
-
At the blocking stage you don't do final renders, and the difference in time saved by excluding repeated frames from a shaded render will be negligible. If you did want final renders at the blocking stage you could give A:M a custom list of frame numbers to render in the frame range parameter.
-
Consider this... what is the prediction doing that makes it faster than the render? It must be leaving something out. That thing left out is what makes the prediction not 100% accurate. In a render with a half million pixel, even a 1% error of pixel wrongly rendered would be noticeable and not useable.
-
I can answer one of these... No, A:M does not. The only test that could ascertain if a pixel in frame 2 is exactly the same as in frame 1 is to fully render it and compare. A faster shortcut test that worked would need to determine every aspect of that pixel to be of any use as a test for this purpose. If it did that, it would also have all the information needed to correctly write that pixel to the image file... IOW it would be rendering the pixel. If there were a faster way of rendering the pixel, that would be used as the renderer. Also, just sampling some pixels in advance won't cover 100% the cases of where pixels could change from frame to frame. Less than 100% would lead to omissions of things that should have been rendered but were presumed to not need to be rendered. If there were some accurate test that wasn't rendering... it would still have to be not just faster per pixel but WAY faster than regular rendering to justify spending CPU time on it that could have been spent on rendering. This is a paraphrase of something Martin said when someone asked why the prediction for how long a frame would take to render wasn't more accurate at the start of the render. Basically, the only way to accurately know how long all the pixels in a frame will take to render is to render them.
-
HAve a good trip, Jason!
-
He looks real good, Rodger! Suggestion... make the first and third fingers shorter than the middle finger to avoid the rake look. The apparent difference in length actually begins at the knuckle line in the hand which is curved and angled rather than straight across the hand.
-
That looks like fun!
-
Kevin, This zip has 8 progressively different OBJs in it. TestCyls.zip Load each one into Lumion and tell me when the first one is that comes in with colors and Group names.
-
Hi Jalih! Tell us more about this step. What did you have to do? Nothing fancy, just deleted the imported color map that looked wrong and loaded the original png file from AM project. Then it was just a matter of scaling, positioning the texture and changing the color of the face material to be same as the rest of the head. I think the problem for Kevin is that Lumion has no model editing capability. It's just a renderer. Everything has to work from imports.
-
Hi Jalih! Tell us more about this step. What did you have to do?
-
We need to Skype about this. There is too much getting lost on the forum here.
-
I'm lost. Not getting groups from A:M was the problem that had to be solved but the groups have been coming through all along? What is the problem we are trying to solve?
-
That is also success. If you turn that so the other side is facing the camera does the other side become visible?
-
What about groups? Do you have any identification of Groups on that model when it's in Lumion?
-
These problems aren't solved by loading a complex model and finding that it doesn't work. You start with a very simple model and try small changes until it does work It has color? That is success. That's all I needed to work. Now I can go on to the next step. That was an A:M OBJ with a Blender MTL. All we have to do now is find out what is the key difference that stops the A:M MTL from being used. There's probably just one line in this that is the problem...
-
Import this into Lumion and tell me what you get TestCyl5.zip
-
Try opening this OBJ in Blender. This was exported from an A:M model that had a simple material on each Group. TestCyl3.zip When I import it in Blender the top is Red and the bottom is Green. Where do i look for "Groups" in Blender
-
Does that testCyl2.OBJ load with color for you? All i did was change the color chip in the Surface Properties of the Group and named the Group. No materials. You don't need A:M materials anyway if you have to re texture it all in Lumion, right? You just want Groups, right?
-
Here is my test model made with groups in A:M and exported to OBJ. TestCyl2.zip When I import that in Blender it has colors. I don't know how to see Groups in Blender but they must be there too. Now... why is it that when you import an OBJ from A:M you don't get any colors or groups?
-
I don't know if it is or isn't about spaces in 3DS. OBJ models DO have color. It's stored in the companion MTL file I do know that if i try to import "Cube creation Y&G.obj" to A:M I get the shape but no colors and no groups. If I remove the spaces from the file names AND from the references to those names INSIDE the files, A:M loads the OBJ and the groups with color. The Groups just have numbers without names but at least they are groups. First lesson: Don't make anything at any step of the process with a space in a name (even if it's a group name) and for now... don't use more than 8 characters while you are doing tests. I also just noticed that the ampersand (&) is trouble. Just use letters and numbers in your names for now I will get Blender and see if there are any obvious fixes. This is your blender model after I deleted all the spaces in the file names. It came in with groups and colors.
-
Now we can put two files that should be the same thing side-by-side and see what is different and if it's important. There's a lot that is different. First possible clue... A:M doesn't handle names with spaces when it's trying to import and OBJ file.
-
When you reload that OBJ you made, the groups come in correctly colored and named, right?
-
Do this Here is lathed cylinder exported as OBJ from A:M TestCyl.zip Load it into Blender Make a Group on the top half and make it Yellow and name it "Yellow" Make a Group on the bottom Half and make it 50% gray and name it "Gray" Save the new model as a native Blender file (if it's asking to subdivide anything, don't let it) Close Blender Reopen Blender and reload the Blender version Export that to OBJ with a new name (if it's asking to subdivide anything, don't let it) Send me the new OBJ and MTL files
-
Now I need a cube exported to OBJ from A:M with the same group names, with the same colors, in the same places on the model.
-
That is only one file and it's not in ASCII text format and it's not OBJ. 3Ds isn't going to help us. We need to work with OBJ because that can be a text file. I need the four the four files I listed and I need them in ASCII text. See how they have readable text and readable formatting... example OBJ: # OBJ - Exported from Animation Master # 1OBJ mtllib CYL.mtl o CYL.OBJ v 6.76197 21.8464 0 v 4.79586 21.8464 4.79586 v 4.24249 15.8275 4.24249 v 5.98175 15.8275 0 v 3.68912 9.80858 3.68912 v 5.20152 9.80858 0 v 8.06357e-08 21.8464 6.76197 v 7.13316e-08 15.8275 5.98175 v 6.20275e-08 9.80858 5.20152 v 4.24249 15.8275 -4.24249 v 4.79586 21.8464 -4.79586 v 4.51609e-07 15.8275 -5.98175 v 5.10515e-07 21.8464 -6.76197 v 3.68912 9.80858 -3.68912 v 3.92704e-07 9.80858 -5.20152 v -4.24249 15.8275 -4.24249 v -4.79586 21.8464 -4.79586 v -5.98175 15.8275 -9.03218e-07 v -6.76197 21.8464 -1.02103e-06 v -3.68912 9.80858 -3.68912 v -5.20152 9.80858 -7.85407e-07 v -4.24249 15.8275 4.24249 v -4.79586 21.8464 4.79586 v -3.68912 9.80858 3.68912 # 24 verticies vt 0.00000 1.00000 # 1 texture coordinates g default s 1 usemtl UnKnown0 f 1/1/1 2/1/2 3/1/3 4/1/4 f 4/1/4 3/1/3 5/1/5 6/1/6 f 2/1/2 7/1/7 8/1/8 3/1/3 f 3/1/3 8/1/8 9/1/9 5/1/5 f 1/1/1 4/1/4 10/1/10 11/1/11 f 11/1/11 10/1/10 12/1/12 13/1/13 f 4/1/4 6/1/6 14/1/14 10/1/10 f 10/1/10 14/1/14 15/1/15 12/1/12 f 13/1/13 12/1/12 16/1/16 17/1/17 f 17/1/17 16/1/16 18/1/18 19/1/19 f 12/1/12 15/1/15 20/1/20 16/1/16 f 16/1/16 20/1/20 21/1/21 18/1/18 f 19/1/19 18/1/18 22/1/22 23/1/23 f 23/1/23 22/1/22 8/1/8 7/1/7 f 18/1/18 21/1/21 24/1/24 22/1/22 f 22/1/22 24/1/24 9/1/9 8/1/8 # 16 polygons example MTL: newmtl UnKnown0 Ns 200 Ka 1.000000 1.000000 1.000000 Kd 1.000000 1.000000 1.000000 Ks 1.000000 1.000000 1.000000 d 1.000000 Ni 1.000000 sharpness 1.000000 If it looks like this, it's not ASCII text...