NVil Forum
General Category => Community Help => Topic started by: 3dwizzard on November 29, 2012, 08:50:50 pm
-
Trying to get the grid to match up with centimeters and millimeters.
This box is approximately 15 cm x 21 cm. I'm taking a guess, that it can be adjusted in preferences.
Right now the grid sizes is 25.000.
The problem that I'm having is I'm trying to keep it to Poser scale. I've already changed the import scale from 100, to 1000.
It still seems like it's still coming in, to small.:
(http://www.divshare.com/img/21129252-29d.jpg)
How can I get the grid size to match up to centimeters and millimeters?
-
Can you do this
1. Edit > Preference > General > Unit Setup. Check the 'Generic' option.
2. Create a box of 1x1x1.
3. Export the box to Poser and measure the box size in Poser in millimeters.
Once you have the box's measurement in Poser, I will be able to tell you how to set things up.
-
Thanks IStonia,
I'll do that. ;D
-
Hi IStonia,
3. Export the box to Poser and measure the box size in Poser in millimeters.
I know no way to measure an object in Poser. You would need to "best guess" the size compared to the character being used (all characters are slightly different sizes).
-
Hi IStonia,
3. Export the box to Poser and measure the box size in Poser in millimeters.
I know no way to measure an object in Poser. You would need to "best guess" the size compared to the character being used (all characters are slightly different sizes).
Another way is to import a standard character from Poser and measure its height in generic unit. 3dwizzard, can you do this?
-
Hi IStonia,
As I am curious of your method, I will jump in. Hope that is OK.
I have imported a standard Poser "Simon G2", importing at scale = 1.0000, its hight is 0.7542 units.
[for information. Different Poser character size (units) can be found here:- http://www.morphography.uk.vu/scaleobj.html )
@3dwizzard,
If you post the size as requested, I will exit the thread until you are done.
-
I see now. It was set up right. I just didn't know you could only see it in Orthographic views.
And you really have to zoom in close.
(http://www.divshare.com/img/21131358-62e.jpg)
My question should have been. Can you set up the workplane to match millimeters at this scale?
Sorry for the confusion. I never worked with the workplane before.
-
Hi 3dwizzard :)
When we looked at this previously, we where looking at setting the grid based on imported figure. It was so the grid reflected the size of the import. From your first post, you now want to have your import sync with the grid, which is different.
In your first post, you show you want the grid to show the size of model in cm. To do that, you would need to change the unit setting to "0.100 as one MM", so that each grid spacing is 1 cm. You would then need to change the import/export to get your character/objects to import/export correctly.
For an example:
I set the "0.100 as one MM"
The character I am importing is (I decided) 6 feet tall (6 x 12 x 2.54 = 182.8 cm). The actual characters hight, by default is 0.7542 units. I change the import scale to 242.376 (182.8 / 0.7542), that then brings in the character at 1.828 meters (182.8 cm). The export then needs to be set at 0.004
I forgot to add:- In the "Edit -> Preference" I set the "Grid" "floor grid"/"workplane grid" "Interval" to 1.000 to give the correct spacing of 1 grid space = 1 cm. You can adjust that as needed. If for example, you are creating small detail, you could change the grid interval down to (for example) 0.1, which would then give a grid spacing of 1 mm
Of course, there may be an easier way to do this, that is why I am curious as to how IStonia would set this up.
-
Here is my method. Please use the new update version.
1. Calculate unit scale.
The character real world height = 1828 mm.
The character system height = 0.7542 unit.
Unit scale = 0.7542/1828 = 0.000413.
2. Set unit scale.
Open the 'Preference' form. Edit > Preference. Open the 'General' tab. In 'Unit Setup' group, set 0.000413 as MM. Don't forget to check this option as well.
3. Set grid interval.
Open the 'Grid' tab. In 'Floor Grid' group, I have
Major Segs = 4.
Minor Segs = 10.
The rough floor size I want = 2000 mm.
The interval value = 2000/(4x10) = 50 mm.
type 50 into the 'Interval' field.
4. Click 'Apply' button.
Steve, if your scene scale is not 0.001, set it to 0.001. The grid size will change, so you need to set grid interval to 50mm again.
To check weather the scene scale is good, do 'View > Reset View' on a perspective viewport. If it is good, the grid size should be not too small not too big.
-
Hi IStonia,
I see you have made some changes to the programme to accommodate, that cheating ::) ;D
Being able to enter the better precision for unit size/grid interval saves the extra steps of scaling the object on import/export. So it does make it more straight forward. Thanks.
-
Hi 3dwizzard,
Where you able to follow?
Do you think a step by step guide may help you/others better?
-
Sorry it's taking so long.
Scale was always hard for me to wrap my head around.
Before it was always coming in, small. Now it's coming in, large.
Not sure what I am doing wrong:
(http://www.divshare.com/img/21176144-a77.jpg)
Another thing I noticed, when I create a box 1 mm x 1 mm x 1 mm. it doesn't look right.
(http://www.divshare.com/img/21176158-147.jpg)
I'm assuming that the grid should measure a centimeter. But this one looks like 2 cm.
If I'm not mistaking, there are 10 mm to 1 cm. Isn't this correct?
-
3d wizzard, in the example, I used informations from steve. Because he uses different import/export scale settings from yours, your settings can't be the same as his.
In your case, do the following.
1. Edit > Preference. Set 0.0413 as one MM. Click 'Apply' button to close.
2. Edit > Preference to bring up the form again. Set your grid interval value to 50 mm. Click 'Apply' button to close.
-
Hi IStonia,
In your case, do the following.
Unfortunately, that would be guessing.
As I mentioned above, in my example, the characters real world hight was decided by me. So the scale/units sizes to set would depend on the character being used and what real world hight the user decide on for that character (or prop). It is a pain, but when they created Poser and the characters, there was never a definitive real world size for any of the characters, they are just "best guessed" by the user.
-
Hi IStonia,
In your case, do the following.
Unfortunately, that would be guessing.
As I mentioned above, in my example, the characters real world hight was decided by me. So the scale/units sizes to set would depend on the character being used and what real world hight the user decide on for that character (or prop). It is a pain, but when they created Poser and the characters, there was never a definitive real world size for any of the characters, they are just "best guessed" by the user.
It may probably be fine. Let's see what the outcome will be.
-
Like I said, scale is very hard for me to wrap my head around.
This is the box that I exported from the other setting.
For a moment I thought I had it. I had to change the import scale to 500.
(http://www.divshare.com/img/21183479-ad7.jpg)
Length and width wise, it's off by 1 cm. The closest I've seen yet.
But when I create a new box with these settings. I lose the centimeter scale:
(http://www.divshare.com/img/21183490-92e.jpg)
???
-
Hi 3dwizzard,
Changing the import scale will cause more problems.
When importing a character, you need to determine its real world size as compared to its actual (generic) size, so you can then adjust the scene scale/unit size to suit. When importing a prop you will need to follow the same route to get the grid to align. (As I mentioned, this is different to what we discussed on another thread)
I do not want to interfere with the thread more, as it appears IStonia wants to deal with this after seeing your results.
-
3dwizzard, since its hard for you to figure out what goes behind the scaling, its better for others to help you to set it up rather than trying out your self.
Did you see and follow my previous post? If you didn't, change your import scale back to 100 and export scale to 0.01. Then see my previous post and set the settings. Once you have done that, I will let you know the next step.
Edit: I see you did follow my previous post from the images your posted. So, just change your import/export scale to where they were before. Then import a standard size character from Poser. I want to see how big it is in the floor grid. Forget about the box for now. Will deal with it later.
-
I've changed the import scale back to 100. Didn't have any problems on the import.
Hopes this helps:
(http://www.divshare.com/img/21184831-21b.jpg)
-
That looks about right. Now we can fine tune the unit setup.
Please check the character height. You can get it from here, 'Scene Explorer' window > Object List > Size.
Tell me the character's size property and her actual height that you think it should be.
-
Thanks IStonia,
This is what I found in the scene explorer object list:
1m 585.6609mm x 1m 715.0800mm x 252.6027
There was two other sizes for left eye, and right eye. But I didn't think you needed that.
-
So the character height is 1.715 meter. If you think her height value is not right, please let me know what it is. Otherwise the unit scale is done and we can deal with the box now.
-
Hi IStonia,
From what I am learning Poser scale seems to be a bit confusing.
According to the link that Steve provided, JessiP6 Poser 6 scale would be 1.86 m.
I exported Jessi from Poser 6.
-
Hi IStonia,
From what I am learning Poser scale seems to be a bit confusing.
According to the link that Steve provided, JessiP6 Poser 6 scale would be 1.86 m.
I exported Jessi from Poser 6.
1.86m can't be for a standard girl. Is Jessi a giant.
Edit: Can you import a male character and check his height?
-
I'm sorry, I was reading that scale wrong. That was the real life height in meters.
The height in Poser Native Units is: 0.70805
-
I looked at the link steve provided and also find it confusing.
Jessi P6 has three heights.
Poser 5 or DAZ|Studio scale : 1.73m
DGS (Doc Geep's Scale) : 1.80m
Poser 6 onwards scale : 1.86m.
It seems Jessi keeps growing. Maybe well over 2.00m by Poser 10. ;D
Let's see what steve think about this.
-
lol, my thoughts exactly. ;D
-
I looked at the link steve provided and also find it confusing.
I did warn you ;D
-
Hi 3dwizzard,
If you want to use that list as a base of the hight(s) of each character, then you can simply use that for the default PNU size.
For example:-
If you decide that the characters are at a standard hight in the Poser5 version scale, then you can use "1 unit = 96 inches (96 x 25.4 = 2438.4mm)
As you currently import at scale of 100, you would calculate by:-
100 divided by 2438.4 = 0.04101
So in NVIL, you would change your units to "0.04101 as one mm"
If you decided differently, and wanted the characters at a standard hight as shown for poser 6, then:-
"1 unit = 103.2 inches (103.2 x 25.4 = 2621.28mm)
So, again, due to the import scale you have set at 100, you would calculate by:-
100 divided by 2621.28 = 0.038149
So in NVIL, you would change your units to "0.038149 as one mm"
Once you have decided what the PNU is to be and made the unit setting. You can change the grid spacing to what you need.
Please note: Doing that is creating the scene for the character at what hight you want it to be. So the box you are looking at may not actually show correct size. You would need to scale the box to the new world scale, so it is of correct size to the characters hight you have decided on.
Does that make sense?
-
Hi steve,
I think I would like to go with 103.2 inches. It seems to be the scale for P6 and up.
Is that 25.4 a constant for converting inches to mm?
Once you have decided what the PNU is to be and made the unit setting. You can change the grid spacing to what you need.
How would I do that? Is that when you change interval? If so, to what?
Please note: Doing that is creating the scene for the character at what hight you want it to be. So the box you are looking at may not actually show correct size.
You would need to scale the box to the new world scale, so it is of correct size to the characters hight you have decided on.
I'm not too concerned with that box. It was just for reference.
What I would really like, is to create a box to Poser scale. And be able to use the cm & mm grid for a reference while I'm modeling.
-
Hi 3dwizzard,
I think I would like to go with 103.2 inches. It seems to be the scale for P6 and up.
OK, no problem.
Is that 25.4 a constant for converting inches to mm?
Yes,
How would I do that? Is that when you change interval? If so, to what?
Yes, change the "Preference -> Grid -> Interval". As to what interval, that would depend on what you are working on. You could set the interval to 1mm if working on something small, or set it to 50 mm if working on somethin larger. The interval will not change the scene scale, it only changes the grid density (how many lines you see) and therefore the distance you have snapping points on the grid.
What I would really like, is to create a box to Poser scale. And be able to use the cm & mm grid for a reference while I'm modeling.
You can do that once set.
You can leave the .obj import/export scale as you have set.
We will set the Grid Interval for a character, which due to the character size, we do not want the grid to be too dense (too many line).
The setting to make in NVIL are:-
"Edit -> Preference -> General" -> "Unit setup" -> "0.038149 as one mm"
"Edit -> Preference -> Grid" -> You can set all 3 "Interval" to 50 mm
Now import the character and check the hight (the size in Y direction). "Jessi P6" will show as being 1.86m (the hight shown on the chart I linked to).
When you now open NVIL, that scale will be set.
You may need to change the "Grid -> Interval", but that Interval will depend on what you actually want.
If you want to work to cm, have the "Grid Interval" set to 10mm (1 cm = 10 mm).
Can you follow that OK?
Just ask if anything unclear.
-
Hi steve,
I'm beginning to see now. The scale is dependent on figured that you are using.
And the grid is determined by the intervals. So if you set it to 10 mm. Your grid will show
centimeters squares. If you set the intervals to 50 mm. Your grid will show 5 cm squares.
I just set it to 100 mm, and it looks like 10 cm squares to me.
What does the view grid intervals do? I change the settings, and I don't see nothing happening.
-
Hi 3dwizzard,
I'm beginning to see now. The scale is dependent on figured that you are using.
Yes.
What we are now doing is setting the scale to what is put forward as being the scene scale in poser 6. So once the unit size is set in NVIL, all the characters, when imported into NVIL, will be the hight as shown in the list (I linked to).
And the grid is determined by the intervals. So if you set it to 10 mm. Your grid will show
centimeters squares. If you set the intervals to 50 mm. Your grid will show 5 cm squares.
I just set it to 100 mm, and it looks like 10 cm squares to me.
That is correct, yes.
What does the view grid intervals do? I change the settings, and I don't see nothing happening.
That is for setting the grid intervals for the orthographic views (front, top, left right etc). That will set the default grid size (when that view is reset).
Note:-
That can get a little confusing as the grid for those views is dynamic, meaning the grid will change as you zoom in/out. The easiest way to keep a check on the grid, is "View -> Display -> Heads up Display" and enable "Show view Size" That will add information as to "View size" and "Grid"
Here is that option enabled. I am in the "Front view" at default. The readout shows the grid at 1.0000 (which is the interval I have set.)
(http://i.imgur.com/jicUG.jpg)
As I zoom in on that view, the grid changes, but I can see from that readout what the new grid interval is:-
(http://i.imgur.com/g551m.jpg)
I am not quite sure as to why it does that in the orographic locked views (although I do find it useful), or as to why it does not do that in the Perspective (unlocked) views. IStonia would need to answer that.
-
I am not quite sure as to why it does that in the orographic locked views (although I do find it useful), or as to why it does not do that in the Perspective (unlocked) views. IStonia would need to answer that.
The print out spacing value is the actual spacing between visible grid lines. Since the grid lines keep changing as you zoom in/out in orthographic view, the print out value will change to reflect it. It does that too in perspective view if you change the scene scale.
3dwizzard, make sure you have the right scene scale, 0.1. Some calcualation operations are scene scale dependent. Keep it right and you will avoid some unexpected problems.
-
I am not quite sure as to why it does that in the orographic locked views (although I do find it useful), or as to why it does not do that in the Perspective (unlocked) views. IStonia would need to answer that.
The print out spacing value is the actual spacing between visible grid lines. Since the grid lines keep changing as you zoom in/out in orthographic view, the print out value will change to reflect it. It does that too in perspective view if you change the scene scale.
That does not answer the actual question as to why the grid line spacing changes as you zoom in/out in orthographic view, but not in Perspective view.
-
This brings more questions,
make sure you have the right scene scale, 0.1. Some calcualation operations are scene scale dependent.
Why have a base/default scene scale of 0.1?
I would normally always go with a base/default scale of 1
Keep it right and you will avoid some unexpected problems.
That puts forward that changing the scene scale can give unexpected results. Such as what?
-
I am not quite sure as to why it does that in the orographic locked views (although I do find it useful), or as to why it does not do that in the Perspective (unlocked) views. IStonia would need to answer that.
The print out spacing value is the actual spacing between visible grid lines. Since the grid lines keep changing as you zoom in/out in orthographic view, the print out value will change to reflect it. It does that too in perspective view if you change the scene scale.
That does not answer the actual question as to why the grid line spacing changes as you zoom in/out in orthographic view, but not in Perspective view.
I don't know wheather it's a good idea to do that. Also I don't have a good idea of how to do it.
-
This brings more questions,
make sure you have the right scene scale, 0.1. Some calcualation operations are scene scale dependent.
Why have a base/default scene scale of 0.1?
I would normally always go with a base/default scale of 1
Keep it right and you will avoid some unexpected problems.
That puts forward that changing the scene scale can give unexpected results. Such as what?
0.1 scene scale is not the default value. It refers to 3dwizzard's setting. The default scene scale is 1.
The scene scale affects the soft selection range. I remember that you know that. Also, it affects the value zero rounding threshold in cut and boolean operations. There are also a few other things like view reset, retopo offset, etc.
-
0.1 scene scale is not the default value. It refers to 3dwizzard's setting. The default scene scale is 1.
The default scene scale setting is 0.1 That is the setting by default, the setting in place from a new start up configuration.
You can reset the scale, which takes it to 1. But why would you need (or be expected) to reset the scale to get it to default when you have not changed it from installation default?
-
0.1 scene scale is not the default value. It refers to 3dwizzard's setting. The default scene scale is 1.
The default scene scale setting is 0.1 That is the setting by default, the setting in place from a new start up configuration.
You can reset the scale, which takes it to 1. But why would you need (or be expected) to reset the scale to get it to default when you have not changed it from installation default?
There is a bug. I will fix it.
Edit: Currently, a very few settings are still stored in registry. I will move them to the app setting file. But the registry settings will not get deleted as it has been being used. So if you delete your setting files, the registry settings will take over. Your will not get your default settings unless your delete the registry settings.
-
Are these the scene setting you guys are talking about?:
(http://www.divshare.com/img/21358657-a04.jpg)
I'm still confused as to what I should set this.
The print out spacing value is the actual spacing between visible grid lines. Since the grid lines keep changing as you zoom in/out in orthographic view, the print out value will change to reflect it. It does that too in perspective view if you change the scene scale.
Does this mean we can actually print out with the grid lines on it? If so, how do we print out?
I've already tried Ctrl+P, and nothing happened.
-
Yes, you just need to set it to 0.1. That the value most suits your settings. It is currently 10 in your screen shot.
The "Print out" I used here actually means "Displaying". I can see them in your screen shot, Floor 10.0000mm 10.0000mm.
-
Hi IStonia,
I just did this settings to 0.1 as you can see it was very small:
(http://www.divshare.com/img/21369643-1a0.jpg)
The black is the inside of the box. I adjusted this setting to 1.
It was better, but still small.
10 seems to be just about right. But I wondered how it would import into Poser.
So I imported it into, Poser 6, Poser 7, and Poser Pro. I had no problems.
It imported very nicely, and seem to scale:
(http://www.divshare.com/img/21369649-9ce.jpg)
Do you think I'll have problems down the road with this?
It seems to be working fine right now.
-
Hi 3dwizzard,
I just did this settings to 0.1 as you can see it was very small:
When you change the "Scene scale" that also automatically changes the "Grid Intervals", so the "Grid intervals" need to be changed to be corrected.
So,... Change the "Scene scale" to 0.1. Go into "Preference -> Grid" and change the Intervals to what they should be. You should then go to [top menu]"View" and select "Reset View". Check how the grid looks then, it should be OK.
I know this can be a bit confusing, but once set, you will not need to change again.
-
I know this can be a bit confusing, but once set, you will not need to change again.
What about some standard settings? With measurements where the Grid Interval fits to the Scene Scale? This would reduce the confusion quite a bit :)
I think of a 1x1x1 box here, imported from the common packages and tools. Where you know that they are 1x1x1 meter in let`s say Blender. Or Unity. Or Max. Or Cine. Or ... . And where you simply can choose from a dropdown list to have a equal grid and scene setup then.
-
Is it possible to have a standard setting?
First thing I want to know is which is standard, imperial or metric?
-
What about some standard settings? With measurements where the Grid Interval fits to the Scene Scale? This would reduce the confusion quite a bit :)
It is not necessarily a case of the grid interval fitting to scene scale, but the scene scale being good for an objects size.
It is why during this [threads] scene scale process, we import a character and set the scene scale to that (the grid interval then adjusted as needed).
I think of a 1x1x1 box here, imported from the common packages and tools. Where you know that they are 1x1x1 meter in let`s say Blender. Or Unity. Or Max. Or Cine. Or ... . And where you simply can choose from a dropdown list to have a equal grid and scene setup then.
Even in applications where you can have a scene set to specific units (mm/cm or inch's etc), that is for display and possible export conversion, where you may (for simple example) create an object in mm, but want to export as cm. There can then be a conversion/calculation for the adjustment on export.
In the most common format ".obj" there is no way to place what a unit actually is.
-
I would say yes it is possible to have a standard setting.
Most packages have something like a standard setting. And they all seem to use a somehow equal metric standard. I´ve never seen a factor of let`s say 0.73 to fit from one package to another. It`s more 1.0,0.1,0.01 or 10, 100 and 1000. If even. A meter or a 1.0 in trueSpace is a meter or a 1.0 in Blender too. But i remember dxf files that i had to scale down by a factor of 100 to get a useful result that fits into the workspace.
I can of course just speak for my pipeline. Which includes Blender, trueSpace, Ultimate Unwrap 3D and Unity. And a few long forgotten tools and engines. A blender cube imports with the size of 2x2x2 in trueSpace and Ultimate Unwrap 3D just fine, and displays the same size and units in all three packages. Same goes for the cube in Unity then. They all use the same unit setup it seems.
If you call it meter or apple doesn`t really matter. The important part is that 1 unit in blender is 1 unit in Unity. And that the workspace is setup in a way that you can work with a standard 2.0 x 2.0 x 2.0 cube then. When i remember right this isn`t the case with Nvil at the moment.
Interpolated from that, and since Unity is a big player, i would say that packages like Max, Maya or Cinema4d are not this different here. Unity is made to fit to the big players in the first place.
Another hint gets delivered by the file formats. A unit of 1.0 in an Obj file is most probably a meter unit in one of the packages.
Maybe somebody else can share his experiences and thoughts here too :)
-
Cross posting with steve. I hope we don`t interfere too much here :)
Short of time at the moment. Just this point ...
In the most common format ".obj" there is no way to place what a unit actually is.
Obj unit range goes from 0.000001 to 999999.000000
One unit is 1.0 :)
-
Obj unit range goes from 0.000001 to 999999.000000
One unit is 1.0 :)
One what? mile/foot/inch/mm/cm/meter/???
You cannot set a scene scale until you decide as to what the units are to be, and what size the object(s) will be.
-
Another hint gets delivered by the file formats. A unit of 1.0 in an Obj file is most probably a meter unit in one of the packages.
It is not possible or wise to make such an assumption.
For example. You could be importing a model of an house and due to its size assume that the units are meters, but then find (after import) when the model was made, it was made in units of mm due to added detail.
-
Tiles, imagine you model an inset, then next you model a planet the size of the earth. How do you set up the measurement in TS?
-
By switching the unit resolution of course. I model such a planet nevertheless in Meters in most cases. And scale it into the needed size when done.
You have to fit your workspace to the most common modeling situation as the standard setup. And here the most common things are characters and buildings. So meter is a good thing. And gets used as the standard setup by most other modeling apps. To model planets in the planet size is a rare thing and uncommon.
One what? mile/foot/inch/mm/cm/meter/???
One standard unit. Which is in most packages one meter. As told, it doesn`t really matter how you call it. You can call it apple or meter. The vital part is that a standard unit of 1.0 is pretty equal 1.0 in nearly all 3d packages. Conversions from Meter to Milimeter or Kilometer or inches asides.
For example. You could be importing a model of an house and due to its size assume that the units are meters, but then find (after import) when the model was made, it was made in units of mm due to added detail.
When it`s in mm, then it would export and import in the Obj unit size of 0.01.
The vital part again is that one standard unit is one standard unit. A cube from Blender with its 2/2/2 should not import into Nvil as a tiny something in the size of a pixel that resides in the middle of the workspace. (That`s how it is at the moment when i remember right, i have modified the grid some time ago). But also not as a big block where you need several minutes of scrolling to reach the faces.
It is not possible or wise to make such an assumption.
It may not be wise, but it`s pretty practical. And it is already possible and reality in several packages.
I think i`ve told it before, sometimes it`s a wise decision to have a look at the other common packages. I can move my standard cube from one common package to another common package without the need to fiddle around with the import settings. That`s why i have named my pipeline software. They all will display this standard cube in a useful size with a useful grid setup in the workspace. Something that isn`t the case with Nvil at the moment.
I get of course your point with the conversion. But nobody says that a conversion from let`s say meters to kilometers is forbidden then. This can be done while im- or export for example. Or by a switch in the software. That`s what trueSpace has in its object info panel. You can set the units to several formats and needs.
A standard meter cube from Blender nevertheless imports as a standard meter cube into trueSpace and Unity. Meter is the most common and most used unit from what i know.
In this shot i have converted a cube that had around 1.5 meters to kilometers. And then switched the units back. Now it has 1500 meters ...
-
One standard unit. Which is in most packages one meter.
Which packages?. For example, C4D by default works in units of CM, and a default box/cube is 200 x 200 x 200
As told, it doesn`t really matter how you call it. You can call it apple or meter. The vital part is that a standard unit of 1.0 is pretty equal 1.0 in nearly all 3d packages. Conversions from Meter to Milimeter or Kilometer or inches asides.
A unit is a unit, yes. But it depends on what the user decides a units size is.
When it`s in mm, then it would export and import in the Obj unit size of 0.01.
You are assuming that it is the same user exporting/importing between applications and has decided on what a unit size is, or at least, that some standard unit size as been agreed between all users of all software. Even the vendors cannot decide on that.
The vital part again is that one standard unit is one standard unit.
But it is. But it also depends on what unit size is decided upon.
A cube from Blender with its 2/2/2 should not import into Nvil as a tiny something in the size of a pixel that resides in the middle of the workspace. (That`s how it is at the moment when i remember right, i have modified the grid some time ago). But also not as a big block where you need several minutes of scrolling to reach the faces.
You are going from a specific size. You cannot set a workable grid/scale until you know the size of an object and the units is as been built in.
It may not be wise, but it`s pretty practical. And it is already possible and reality in several packages.
Again I ask, which packages?
I think i`ve told it before, sometimes it`s a wise decision to have a look at the other common packages. I can move my standard cube from one common package to another common package without the need to fiddle around with the import settings.
Import/export settings are not the same as "scene scale". Show me where in the other packages a "scene scale" adjustment can be made.
That`s why i have named my pipeline software. They all will display this standard cube in a useful size with a useful grid setup in the workspace. Something that isn`t the case with Nvil at the moment.
A cube of 1 x 1 x 1 will import (by default) into NVIL as, surprisingly as it may be to you, as 1 x 1 x 1. A specific grid size is only good for a model that would use that grid size.
A standard meter cube from Blender nevertheless imports as a standard meter cube into trueSpace and Unity. Meter is the most common and most used unit from what i know.
There is no such thing as a "standard meter cube". For characters, look at Daz studio, 1 unit = 2.4384 m, in Poser, 1 unit can be either 2.4384m, 2.54m or 2.62128m. or even something completely different.
In this shot i have converted a cube that had around 1.5 meters to kilometers. And then switched the units back. Now it has 1500 meters ...
Why would/should switching from meters to kilometers then back again to meters change the size of the object. That sounds like a bug.
-
Is it possible to have a standard setting?
It appears to me (and of course I could be wrong), that Tiles is looking for a default setup whereas the "Generic" unit setup would be equal to:-
Scale = 1
Unit: 100 as one meter
Grid Interval 1m
(which currently equates to a generic unit setup with grid interval =1 and scene scale of 0.01)
That would show a 1x1x1 cube as a reasonable size to view object on import/ view reset.
To add: Although I have no real issue with current defaults, I have always wondered as to why the default grid is 25 units?.
-
Which packages?. For example, C4D by default works in units of CM, and a default box/cube is 200 x 200 x 200
Which makes a standard cube of 2x2x2 meters ;)
Again I ask, which packages?
I already named four of them that works pretty good together, and somehow share the same unit setup. That`s Blender, trueSpace, Ultimate Unwrap 3D and Unity. How many more do you need?
I know that the game engine Unreal also uses a unit system that imports equal like Unity. I know that the Game engine Acknex7 also works with a standard unit that works just fine with the meter units. If not they would have problems with their physics engines. That`s where it is important to have a useful standard unit. I remember two or three more smaller unknown packages like roadkill that also works just fine with meter units.
Cinema 4D is fine with that too when you set the Units to meters. Interestingly enough it seems that the old cine versions did use meters as the default units too. This was changed with r12 or r13. For no known reason. The cine users that i have asked uses meters ...
Max uses so called generic units. But even here you can set the units to meters, and all is fine. Max imports the cube a bit small but not too tiny from what a max user told me. So even here it seems to fit.
Anyways. I´ve attached a standard Blender cube in Obj format. That way you can have a look. And you can have a look at the values in the obj file. They go from -1 to 1. Means this cube is 2x2x2 units big.
By the way where does Nvil store the grid setup? In the Digitalfossils folder or in the registry somewhere? I just imported this standard cube and it looks fine. But i remember that it looked very very tiny when i did this in the past. I`ve removed the Digitalfossils folder to have the default setup. And am unsure if this is my own setup, or the current standard Nvil setup.
-
It appears to me (and of course I could be wrong), that Tiles is looking for a default setup whereas the "Generic" unit setup would be equal to:-
Scale = 1
Unit: 100 as one meter
Grid Interval 1m
(which currently equates to a generic unit setup with grid interval =1 and scene scale of 0.01)
That would show a 1x1x1 cube as a reasonable size to view object on import/ view reset.
Hm, i am looking more for a unit of 1 equal 1 meter. Which needs to be displayed in the viewport in a reasonable size. But in general, yes. Something like that :)
-
Which packages?. For example, C4D by default works in units of CM, and a default box/cube is 200 x 200 x 200
Which makes a standard cube of 2x2x2 meters ;)
It does not work like that. If you export that 200x200x200 cube at defaults (.obj format), it would import into other applications at those 200x200x200 units. Where is the global cross platform meter sized cube you mention there?
I already named four of them that works pretty good together, and somehow share the same unit setup. That`s Blender, trueSpace, Ultimate Unwrap 3D and Unity. How many more do you need?
They do not share a unit setup. Blender does not have unit sizes, neither does Unwrap 3d.
What is the default units size given in Truespace, is it meters?
I know that the game engine Unreal also uses a unit system that imports equal like Unity. I know that the Game engine Acknex7 also works with a standard unit that works just fine with the meter units. If not they would have problems with their physics engines. That`s where it is important to have a useful standard unit. I remember two or three more smaller unknown packages like roadkill that also works just fine with meter units.
Why do you keep going on about meter units, I know of no 3d modeling/rendering application (that as unit sizes) that as a default of 1 unit = 1 meter.
Cinema 4D is fine with that too when you set the Units to meters.
Wow, you are really hard work.
Max uses so called generic units.
They all use generic units, it is just the user can decide if they want those units to represent a specific size.
Anyways. I´ve attached a standard Blender cube in Obj format. That way you can have a look. And you can have a look at the values in the obj file. They go from -1 to 1. Means this cube is 2x2x2 units big.
Where in an .obj file does it state those units are meters?
-
It appears to me (and of course I could be wrong), that Tiles is looking for a default setup whereas the "Generic" unit setup would be equal to:-
Scale = 1
Unit: 100 as one meter
Grid Interval 1m
(which currently equates to a generic unit setup with grid interval =1 and scene scale of 0.01)
That would show a 1x1x1 cube as a reasonable size to view object on import/ view reset.
Hm, i am looking more for a unit of 1 equal 1 meter. Which needs to be displayed in the viewport in a reasonable size. But in general, yes. Something like that :)
Then why not setup as I have shown, job done. ;) :)
-
It does not work like that. If you export that 200x200x200 cube at defaults (.obj format), it would import into other applications at those 200x200x200 units. Where is the global cross platform meter sized cube you mention there?
Are you sure? Then this would be a odd behaviour of the cine obj exporter. A trueSpace cube of 200 cm still exports as 2x2x2 units.
Where have i said that a unit really needs to be one meter? Of course they all are generic. And i said more than once that you can call it apple too. What i said is that one unit is one unit in all apps. No matter how it gets called. And they fit to each other because one unit gets handlet as one unit. That`s the important bit. When i export a blender cube in one unit size then it imports as one unit size in all other apps too. And in all apps i have a look at a proper sized cube after import. And don`t need to zoom in or out dramatically to show it.
Nevertheless, one meter as one unit is somehow common. And that`s what i also said. Even cine uses a metric system, but has decided to use centimeters and not longer meters as the standard for an odd reason since two or three versions. Game engines usually uses one unit as meter because that`s needed by the physics engines to get proper calculations.
Then why not setup as I have shown, job done. ;) :)
And why not simply make this setting to a standard setup so that nobody has to setup it by himself? That`s what this discussion is about at the moment :)
I share your question about the grid resolution by the way. It`s a bit odd :)
-
Are you sure?
Yes. I have C4d R13 installed
And why not simply make this setting to a standard setup so that nobody has to setup it by himself?
Not everyone builds objects to 1 unit size, nor probably import 1 unit sized blocks. They will, like me, probably create the scene scale/grid settings on a per model basis as needed.
-
It`s nevertheless good to have a standard setup :)
-
A blender cube imports with the size of 2x2x2 in trueSpace
I have just been looking a TS 7.6
By default: The default .obj importer and the LUUV importer both import (into a new default scene) a default blender cube of 2x2x2 at 8x8x8. So you must of changed the default settings.
-
It`s nevertheless good to have a standard setup :)
There is already a standard setup for NVIL, it is just that you do not like it.
-
Because it could be better. And iStonia asked for a possible standard setup :)
-
Because it could be better.
All you have put forward up to now, is to change default so it would be better for importing a 1 or 2 units sized cube.
And iStonia asked for a possible standard setup
No, he askedIs it possible to have a standard setting?
which is not the same.
Try using "Best fit"[F6].
-
Hi Steve,
It worked perfectly. Thank you, and thank you IStonia.
You guys helped me with a better understanding of scale. Something that has been a mystery
to me for years. Again thank you!
Oh, I see this went viral. Just wanted to thank you guys for the help. Thanks ;D
-
Hi 3dwizzard,
You are welcome, and good to hear now working well.
Oh, I see this went viral
I think Tiles is looking for a new mission now he has finished the icons ::) ;D
-
Steve, with all now finally lost respect, what the fuck do you think you are doing here? I mean, it can`t be any more obvious, can it?
This thread here for example went as surreal as a dali image now.
I tell iStonia about how other apps handle the unit thing. And that it may be a good idea to do the same. You jump onto the table and declare this as wrong in general.
I deliver hard provable facts and hard values to prove my point. I even deliver an explanation why it is the way it is. See Physics engines. See values in an Obj file. You simply ignore them. Or declare them as wrong again.
I tell you the apps where it works. You ask me to name a few apps, because i haven`t yet. That one was a really funny one.
I name even more apps where it works this way. You tell me this all is wrong because Cine doesn`t work this way. And when it`s not 100% then it`s 0%, right? Just to prove me wrong ...
I tell you that even Cine works that way when you change the units to meters. You tell me this is wrong, because the standard units are centimeters. Unchangeable of course ... . No, they are changeable. And every cine user i have asked has already changed it back to meters. And i know quite a few, being a moderator at a german 3D board.
You played the big guardian here in this thread, ignoring and twisting facts where ever it fits best to your strategy. Just reading the bits where you can prove me wrong. Not the first time that you are trying to protect iStonia from the evil world of any new ideas, or maybe even changings, Yikes!
And now you accuse me to be on a mission? I mean, honestly, and to repeat it, WHAT THE FUCK?
There`s already more than one thread where you are trying hard to make me look like a moron in the one or another way. It is simply too obvious to be ignored any longer. What is it? Are you scared to loose the number one position of the most loved Nvil fans? I don`t want this position, thanks. I´m only interested to have some fun here and there. And shaping the icons was fun. That was the reason why i made them. Not to fawn towards iStonia or to steal you the position of the Number one fan.
I hate fanboys with a passion anyways. There`s nothing worse. I don`t want to be one. I´ve seen software dying at fanboys, and i start to see the same patterns here again. I was even the goal of my own fanboys before too. I develop games. No sir, that`s nothing i like.
And you act like a very bad fanboy here in this thread.
Now i know why Nvil has so few active members at this board. Five when i count right. Now that`s big masses of happy users, isn`t it? You do a really good job here Steve!
But okay, you won. I will not touch this forum anymore. Nvil is completely yours again. I have better things to do.
Kindergarden.
-
No more fire please!
I know you guys just try to help so I can't blame any of you. Discussions are wellcome and very helpfull. But please...
-
I will not quote or reply to most of the post, little point. I will just comment on this section,...
I tell you that even Cine works that way when you change the units to meters. You tell me this is wrong, because the standard units are centimeters. Unchangeable of course ... . No, they are changeable. And every cine user i have asked has already changed it back to meters. And i know quite a few, being a moderator at a german 3D board.
Your main point as been changing the defaults of NVIL to match the defaults of other common applications. I put forward that the defaults in other applications are different. You counter that by saying the users change the defaults to suit. To me that is a contradiction.
One of the applications you put forward, Truespace, as importing a default [.obj) 2x2x2 cube from Blender at the same unit size. I checked and found that to be incorrect, as both its .obj importers by default scale the imported .obj to fit screen. Did you go onto the Caligari forum and ask them to change the defaults so it matches up with blender?, or did you simply change the defaults to suit!
I see no point in trying to change the defaults in NVIL to suit other users settings in various other applications that are probably just as, if not more different between them than the various defaults in place. It is not possible
If the current NVIL defaults are not what the user wants, then like with all the other applications, they can be changed by the user to suit, as you put forward they are already doing in other applications.
-
Anyway, I have changed the default unit setup. It shouldn't affect any existing user settings. Wnen I made the original setup, I had no idea what it should be.
The scene scale definition is changed from
0.001 0.01 0.1 1 10 100 1000
to
0.1 1 10 100 1000 10000 100000
unit setup:
1 as 1 meter
0.001 as 1 millimeter
0.0254 as i inch
grid interval: 25 generic unit
view grid interval: 0.01 generic unit
-
It shouldn't affect any existing user settings.
It does change the users "scene scale" setting. Mine went from 1 to 100.
Just letting you know.
-
I will not quote or reply to most of the post, little point.
Yeah, why should you. You have reached your goal, haven`t you? I exploded. And i will think twice before i start another request. So Congrats.
I`m simply too old for this kind of shit. It steals my lifetime to battle with fanatic software guards. I did this too often in the past. I´m tired of it. I have better things to do.
Your main point as been changing the defaults of NVIL to match the defaults of other common applications. I put forward that the defaults in other applications are different. You counter that by saying the users change the defaults to suit. To me that is a contradiction.
No, they are in fact very common and not different, no matter how much exceptions you deliver. The number of apps where it fits is by classes bigger.
And again you start to twist facts. Yeah, when i twist the facts enough then everything is a contradiction. I just need to twist the facts enough.
This is the outcome when you just read and search for the bits where you want to disagree. And not the whole text.
One of the applications you put forward, Truespace, as importing a default [.obj) 2x2x2 cube from Blender at the same unit size. I checked and found that to be incorrect, as both its .obj importers by default scale the imported .obj to fit screen. Did you go onto the Caligari forum and ask them to change the defaults so it matches up with blender?, or did you simply change the defaults to suit!
There was never a need to. The stuff did and does fit to me. Dunno what you did here.
Hm. You most probably have used the default obj importer from the menu in the modeler side. That one`s known as buggy and useless since ages. It was implemented with trueSpace 3 or 4 in the old millenium. And since this time never changed or fixed. It imports indeed the Blender standard cube with 8x8x8 meters. This is a relict from the times where units was really a big problem for transfer between the apps. Nobody uses this since ages. But yes, that`s nothing that a non tS user knows. So congrats for finding another exception. And in this case you are right.
Use the LUUV plugin. Thats the working obj importer. And this one imports the Blender cube with 2x2x2 meters. Which fits to Blenders 2x2x2 units for a standard cube. Means when you untick Autoscale in its settings, which is again a relict from the old times. Hm, this one should be off anyways. Curious. Anyways. Also the LUUV plugin is very aged. And trueSpace development is stopped since nearly four years now too. There`s by the way a third obj im- and exporter for the workspace side. Which deals the units in a fitting way. And a fourth abandoned one exists too somewhere. Which also has dealt with the units in a similar way. One obj unit equal one meter / one trueSpace unit. But this one did never fully work.
That`s why i have named a whole bunch more common apps, to go around your "i find the grain" attitude. Again, it`s not the exceptions that makes the rule.
I see no point in trying to change the defaults in NVIL to suit other users settings in various other applications that are probably just as, if not more different between them than the various defaults in place. It is not possible
And i already showed you that it is not only possible, but very common out there. Provable in several apps. When you would be right then it would be the exception that you can transfer a cube in 2x2x2 units from one app, and it arrives with 2x2x2 units in the other app. But it is not.
So no further comment besides one comment: Of course it is nothing official where you can rely at. Most of the common modeling apps started like iStonia`s Nvil. With arbitrarily units, not caring for im- and export, since the whole work happened in one app anyways in the old days. That`s where the old hassle with file transfer and fitting scale/units came from in the first place.
But it started to become a problem when you started to unwrap in other apps for example. Or to animate. Or to render. Something that didn`t fit into a pipeline here simply gots dropped.
If the current NVIL defaults are not what the user wants, then like with all the other applications, they can be changed by the user to suit, as you put forward they are already doing in other applications.
And again, then why not make some useful and common default settings in the first place that fits to other apps so that the user doesn`t have to change anything at all for default needs? So that you just need to change it for uncommon cases, and not the regular ones?
Even when you would be right with your points, it`s a win win situation to fit it to the big and common boys since the units are internally arbitrary anyways. And Nvil is not a whole package but just a modeler. So it better fits into a pipeline. This was the whole point of this request. And not to lead a fundamental debate.
Thanks by the way for implementing it :)
-
i dont recall haveing any problems, and my 32x32x32 cube from maya is the same size in nvil
and matches to my grid of 16 units fine.
never had a issue.
also setting so called BETTER defualts, isnt really much of a options since depending on what the user does, they will use units differently.
so why do you got a 5 page thread, on what comes down to individual user preference, when nothing is broken.
-
Again I will not waist to much time quoting/replying to your further rant. Just a quick example of how you obviously do not read the replies, or simply ignore them.
Use the LUUV plugin. Thats the working obj importer. And this one imports the Blender cube with 2x2x2 meters.
No, it does not by default. Have a look at 3rd post on page 5, I posted and stated I had used both importers. Here, I will save you looking:-
A blender cube imports with the size of 2x2x2 in trueSpace
I have just been looking a TS 7.6
By default: The default .obj importer and the LUUV importer both import (into a new default scene) a default blender cube of 2x2x2 at 8x8x8. So you must of changed the default settings.
You need to read the replies put forward, rather than jumping to incorrect conclusions. But then again, you appear to jump to a lot of incorrect conclusions about various applications.
-
And i stated that the default importer is faulty and is not good for useage since the time when it gots introduced. And that LUUV has a checkbox to turn off Autoscale. And stated that those importers are aged. And that there were two new ones for the new part of tS that works like i say. This makes a ratio of 2,5 working in the mentioned way, and 1.5 not. Half because you need to turn off a switch in LUUV to get it working.
And this all with completely outdated obj im- and exporters. trueSpace is out of development for nearly four years now.
That for incorrect conclusions and wrong readings. You sir are the real master here.
I will not waste my time any more with you Steve. Do whatever you want. Twist somebody elses facts. This forum surely has a ignore function. I will turn it on now.
Bye. And best of luck.
-
Hi IStonia,
Anyway, I have changed the default unit setup. It shouldn't affect any existing user settings. Wnen I made the original setup, I had no idea what it should be.
The scene scale definition is changed from
0.001 0.01 0.1 1 10 100 1000
to
0.1 1 10 100 1000 10000 100000
unit setup:
1 as 1 meter
0.001 as 1 millimeter
0.0254 as i inch
grid interval: 25 generic unit
view grid interval: 0.01 generic unit
I see now that you have shifted the scene scale values, as the new "Scene scale "default of 1 is the equivalent of the old 0.01. That of course now as knock on effects when using other functions such as example, the "Soft selection"
You did warn of such problems earlier in the thread when making changes to the "Scene scale" so am now dubious about the new defaults and what other problems there may be.
I suppose I can change my defaults again to suit.
-
I see now that you have shifted the scene scale values, as the new "Scene scale "default of 1 is the equivalent of the old 0.01. That of course now as knock on effects when using other functions such as example, the "Soft selection"
You did warn of such problems earlier in the thread when making changes to the "Scene scale" so am now dubious about the new defaults and what other problems there may be.
I suppose I can change my defaults again to suit.
You don't have to worry about that. As stated, I just change the definition. Because I changed the default scene scale to 0.01 in the old definition but I wanted to call it scene scale 1 instead of 0.01. Just the name, the underlying value remains the same.
-
You don't have to worry about that. As stated, I just change the definition. Because I changed the default scene scale to 0.01 in the old definition but I wanted to call it scene scale 1 instead of 0.01. Just the name, the underlying value remains the same.
Yes, I understand that, that is why I am saying the default "scene scale" in now different and that the functions now react differently when set to that new default.
For me to use the application as I was before, I need to set the default scale value to 100 to get, for example, the same radial soft selection distance as I did before.
You also mentioned possible problems with:-it affects the value zero rounding threshold in cut and boolean operations. There are also a few other things like view reset, retopo offset, etc.
So what effect does the new default "scene scale" have on those?
-
You don't have to worry about that. As stated, I just change the definition. Because I changed the default scene scale to 0.01 in the old definition but I wanted to call it scene scale 1 instead of 0.01. Just the name, the underlying value remains the same.
Yes, I understand that, that is why I am saying the default "scene scale" in now different and that the functions now react differently when set to that new default.
For me to use the application as I was before, I need to set the default scale value to 100 to get, for example, the same radial soft selection distance as I did before.
You also mentioned possible problems with:-it affects the value zero rounding threshold in cut and boolean operations. There are also a few other things like view reset, retopo offset, etc.
So what effect does the new default "scene scale" have on those?
You don't need to change your settings. Every thing should work the same. Just the naming in scene scale change to make the new default scene scale to be called 1, but its real value used in the program is still 0.01. For example, if you change your name from steve to david, your body still remain the same.
-
You don't need to change your settings. Every thing should work the same. Just the naming in scene scale change to make the new default scene scale call 1, but its real value used in the program is still 0.01. For example, if you change your name from steve to david, your body still remain the same.
The new "scene scale" is actually 0.01, but it is changed to name 1, yes.
So, the default "Scene scale" of the programme are now 0.01, which changes the functions of the programme as you have warned (although not explained).
My defaults where "scene scale" 1, but if now set to that, the programme functions are no longer the same (because it is actually set to 0.01), so I have to change the "scene scale" to 100 to get back the same functionality I had before.
If you have an apple and a pear, if you change the names around and I want an apple, then I need to then choose a pear.
Why change the names at all?
-
Why change the names at all?
Because I think "1" more sound like a default setting than the others. I know every new change to the existing may potentially confuse existing users. I don't know any other tool's default setting, but I do know Silo's default setting is at this level. So if new people from an app which has the same default setting or close to that, they may have less trouble on the scaling issue.
-
I know every new change to the existing may potentially confuse existing users.
It is not just possible confusion. You specifically put forward to 3dwizzard earlier in the thread:-
3dwizzard, make sure you have the right scene scale, 0.1. Some calcualation operations are scene scale dependent. Keep it right and you will avoid some unexpected problems.
So will setting 0.1 in the current new configuration cause unexpected problems now? Should he have that setting now at 10?
If you had not changed the defaults, would you advise everyone to set a default scene scale of 0.01?
-
So will setting 0.1 in the current new configuration cause unexpected problems now? Should he have that setting now at 10?
Yes, when he opens the scene scale setting, he will found that the setting is now 10. He will ask "What the ... happened.".
That is not a big issue. He can ask then I can answer. The big issue is I expect new users to have less trouble.
-
But 3dwizzard would not then be using the defaults.
So for clarity, working in a scene with a default setting of 0.01 is not going to cause issues? Those issues that you put forward earlier would actually happen?.
-
I don't unstand the problem you are describing.
If 3dwizzard never open the scene scale again, he'll never know the naming changed. Every thing will work the same as before. Sure he'll know this changes from reading these posts.
-
I don't unstand the problem you are describing.
The new default scene scale is now 0.01 (you have renamed it 1).
You have put forward that the "scene scale" can cause issue. I have asked several times if working in a default scene scale of 0.01 will cause issues you mentioned?
The scene scale affects the soft selection range. I remember that you know that. Also, it affects the value zero rounding threshold in cut and boolean operations. There are also a few other things like view reset, retopo offset, etc.
-
It shouldn't be a problem at all since the underlying scene scale value is not changed. For example, if you set the scene scale to 100(new naming), the actual scene scale the program uses is 1, not 100. As you have stated before, your scene scale is 1(old naming) and now it is presented as 100. Since its scene scale remains as 1, it should not cause any prolem. It is just an interface thing.
-
Sorry, but you are not really seeing my point.
Forget about 3dwizzard setting and forget about my settings.
The new default "scene scale" setting is 0.01
Will that cause issue when using that default?
-
Sorry, but you are not really seeing my point.
Forget about 3dwizzard setting and forget about my settings.
The new default "scene scale" setting is 0.01
Will that cause issue when using that default?
The answer is it won't. At the new default scene scale, the scene scale the program uses is still 0.01 although it is now presented as 1 to user. It is this 0.01 value will be used to calculate soft selection, internal rounding threshold, etc.
-
I do not understand.
You put forward earlier that the "scene scale" can cause issue. But now you put forward that there is no issues with "scene scale" settings.
From the point of soft selection, the issue is easy to see, as with the new defaults only a spherical selection of approx 95 units is allowed.
Ah well, never mind.
-
I may not understand your point correctly. I can't tell wheather you are telling there is a problem or you are not sure of something. I'll try to explain a bit more. I'll take the soft selection as an example.
If you have a scene scale at 1(new naming). The soft selection range would be something like 0 to 100.
If you have a scene scale at 10(new nameing). The soft selection range would be something lik 0 1o 1000.
So if you have a large object but a much small scene scale setting, the soft seletion range may not big enough.
likewise, if you have a small object but a much larger scene scale setting, the available soft selection range may be too much and this may cause problem in soft selection sensitivity in adjusting. That's why it is not a good idea to have a fixed soft selection range of '0 to a very large value' to suit all cases.
So, to avoid any potential problem, select the scene scale to suit object size or scale objects to suit scene scale. Do a 'view reset' will tells you wheather it is set properly, because the distance between the world origin and the camera will be set to a value which is scene scale dependent.
I really don't know how other app handle this. I guess some of them have no scene scale concept at all. Or they just have one and only fixed scene scale, so the only thing people can do or need to do is to scale their objects if they are too big or too small, then use the scale settings in import/export to compensate.
-
I may not understand your point correctly. I can't tell wheather you are telling there is a problem or you are not sure of something.
I am not sure of the information you are putting forward about "unexpected problems" related to "scene scale" where you are mentioning some tools/functions affected, but indicate more, or as to how those tools/functions are actually affected.
I'll try to explain a bit more. I'll take the soft selection as an example.
The "Soft selection" is an example that can be seen by the user, so yes, an easy example. But that in no way explains the other possible problems on the tools/functions you have mentioned, and not mentioned.
So, what tools/functions are affected by scene scale, and just as importantly, how are they affected?
-
The soft selection is the best example to explain how scene scale affect things. In general, a value that is affected by scene scale will get bigger or smaller when the scene scale goes up or down.
There are quite a few of them and I don't have a list in hand and it is not easy to collect them as they spread among codes.
I think it's better not to explain them, because the more I try to explain the more confusing it may get, not every body can understand it well. Users don't have to know about them and better not to know them at all. So far I have little complain about this. You may worry that some very horrible things may happen if the scene scale is not set correctly. I can say that only some minor annoying things may happen. It won't damage or twist object's geometry.
I can see now that scene scale setting can be a very confusing thing for people. I will add an 'Auto Scene Scale' option to let the programe to check the scene and adjust scene scale automatically when needed and you will see the floor grid changes its size. When you decide to stick to a scene scale, you can just turn this option off. Hopefull this can help.
-
I can see now that scene scale setting can be a very confusing thing for people.
It can be confusing when you put forward a warning of having to use correct "scene scale" otherwise "unexpected problems", but then refuse to explain what that warning actually concerns.
Going back to the "soft selection". The only (due to lack of any other explanation) reason I see, to have to change the "scene scale", is due to "soft selection" limitations you have set for its max value, OR, it could be seen as you have intentionally placed the limit of it selection size based on a % of current scene scale rather than a % of current object selection(s)
Another potential problem (due to not knowing what the original problem is), is due to the "scene scale" being based on scene/object full size(number of units). I work on many large objects, but most of the time only work on small sections of that object adding detail. In such a case, should the scene scale be set to the full objects size or the size of the area I am working on?
-
man you guys are really over thinking shit, i just leave the scene scale at what was formally 1 and what is now 100, and just make the grid expand out quite a large distance like 512 to 1024 units, than just work on my environment assets, or if working on something small like a weapon, i still just leave the scene scale alone and tweak the grid settings again, to maybe have smaller grid, and smaller distance between lines.
actually by the way if there isn't already a way to do that, it would be nice to have a command for, taking the interval up and down, and doing the same for the major segments. though that might take a little work since you would need to give control to how much it goes up and down, since i would want to make sure it maintains the power of 2 numbers i use for everything.
with in other packages, controls like that are usually something i script in myself, but that cant really be done with nvil.
-
man you guys are really over thinking shit,
A warning was given by the programmer as to using the application. I am asking questions concerning that warning.
If you think that is "shit" fair enough.
I will ask no more questions!
-
ya but i just test shit out, and make sure it doesn't break my workflows before stressing out about changes like that, and what i saw was so minor it doesn't even matter to me with the change.
you should prolly do the same, work on knocking out some quick shapes, or make a prop, and see if this change effects you or not?
-
Another potential problem (due to not knowing what the original problem is), is due to the "scene scale" being based on scene/object full size(number of units). I work on many large objects, but most of the time only work on small sections of that object adding detail. In such a case, should the scene scale be set to the full objects size or the size of the area I am working on?
I don't know. But if you work on the object's molecule size level, the soft selection won't work properly, otherwise it may or may not. If you want to know exactly the smallest area you can work on without changing the scene scale, I have to check the code and find out the percentage used then you will use that value to apply to your object to get the smallest area value. That would be troublesome.
If the soft selection does not work properly, change scene scale surely can solve it because soft selection range is scene scale dependent instead of object size depenent.
The best thing is just do what you want to do in modeling. If problems occured, we can try to find the solution.
passerby: Just the naming of scene scale is changed. That is my fault. Following is the naming mapping
old new
0.001 0.1
0.01 1
0.1 10
1 100
10 1000
100 10000
1000 100000
Actually, you don't have change your setting at all because it is just naming changing not the value behind it.
-
ya but i just test shit out, and make sure it doesn't break my workflows before stressing out about changes like that, and what i saw was so minor it doesn't even matter to me with the change.
you should prolly do the same, work on knocking out some quick shapes, or make a prop, and see if this change effects you or not?
Interesting way of working.
If I report another bug, I will just put forward I am getting unexpected results, not mention the actual tool/function or the problem, and state you should test shit out to see if you can find the problem.
-
...............the soft selection won't work properly, otherwise it may or may not. .
You appear to be focused now only on the soft selection tool, when you put forward "unexpected problems" with various other tools/functions.
Anyway, forget about it.
-
actually by the way if there isn't already a way to do that, it would be nice to have a command for, taking the interval up and down, and doing the same for the major segments. though that might take a little work since you would need to give control to how much it goes up and down, since i would want to make sure it maintains the power of 2 numbers i use for everything.
Can you give an example of how it works?