Daz 3D is part of 
Connect
DAZ Productions, Inc.
7533 S Center View Ct #4664
West Jordan, UT 84084
Licensing Agreement | Terms of Service | Privacy Policy | EULA
© 2024 Daz Productions Inc. All Rights Reserved.
Comments
I see your issue. There is something I should have spent more time to explain in detail. What happens when you populate a "selected element" is that the Y location of the human being will be, for each element of your selection :
Y value of the selected element which must be populated + Y offset (which is the second dial of the interface)
Knowing what "Yoffset" I should put by default was not easy, because it depends on the options you used when the streets were generated.
1. If you don't use the cityscape terrain, but just a plane primitive (Y=0), and you populate any elements of the created streets without change the default value of the Add Human script, then everybody are on the floor (plane). So if you don't use the cityscape terrain, there should be no issue.
2. If you use the cityscape terrain to create your own streets, then the Y of the houses will vary as a function of the hidden low resolution terrain (cityscape terrain) and of the Y offset you set for the drop. If you set 0 for the offset of the human added, they will be perfectly aligned in Y with the Y of the selected houses. You can try this with a plane called "Cityscape Terrain" which would have Y = -1000 for instance. The issue comes from the slope of the terrain. The altitude for which the house is placed on the floor is maybe not the altitude for which the human are on the floor because of the terrain slope. You can try with another negative Y offset for the human beings (something like -50). There are a lot of parts of the terrain which are flat enough to have a constant Y offset.
I have an appointment, I should be back in 1 hour for the rest of the questions.
I'm gonna have a look at what I can do to have a better behaviour of human Y location on places of the terrain when slopes are more important. In the meantime the best for places with slopes is to populate but before try to change Y offset so that they are more on the floor. On more flat areas you should have no issue.
Thanks a lot for the explanation, V3Digitimes. I will try your suggestions.
I really like the scripts and hope you will continue creating such awesome generators. They will save a lot of time during creating the scenes.
On my renders, I have used procedural terrain included with the set.
I know that the placement is complicated, but hope that with some magic math and your skills we will get it solved.
OK I found the reason why here you have such an offset. In order to fasten the procedure to drop the buildings on the floor, the scripts uses a low resolution (hidden, but you can show it) version of the terrain. If you show the "Cityscape Terrain", which is parented to the "Desert Cityscape Main Terrain", you can see that the human beings are fine on this low res terrain.
I am going to share two scripts in a while (they are presently being tested) to place human beings at the right altitude (Y). The first one is a "redrop" on the low resolution terrain (named cityscape terrain in the scene). It goes fast, but it is not precise (because the terrain is not precise). The second on is a "redrop" on the high resolution terrain. This will necessarily process things a slower way, but this should be extremely precise. I am testing both right now. I just hope we can share dse here.
If you are ok with this, I'll ask for an update where I add these two utility scripts.
Cool Image Simon ! The bloom comes from the skydome too?
Lol I just see the plane right now :)
Thanks for sharing. Yes we made a maximum of optimization so that it renders fast for a maximum of people :)
I'm also so happy people use my sunset !!!!
Yes, the floating people effect comes from the slope of the terrain and the use of a low rez terrain when dropping houses on the cityscape terrain. There is an offset between the low res terrain (hidden) and the terrain. I think using the full resolution terrain would help this (this is an option you have at the bottom of the generator interface, in the menulist, you can choose "Desert Cityscape Main Terrain", but I don't like the slow down of the drop on terrain process for cityscape creation. This is why my recommendation would be to wait for the two scripts (tested, they work), which will come afterwards as an update. I'll make them accessible to you in the meantime. The precise script will allow to drop all the human you select on the terrain bellow them.
I am sorry I have not seen this before because when I populated I was often in the middle of big cities which are pretty flat (so for which the low rez terrain is much closer to the high rez one).
Exactly!! It was encrypted with 4.8.0.59, so it should work for all version including and above 4.8.0.59 !
I'll have to speak with Ansiko, he already made a product on the greek theme, maybe he will be interested.
Thanks for being so indulgent and nice !
I join here the script which will drop the human beings on the high rez terrain. The way to use it is simple. Select all the human beings which are not at the right height regarding the high resolution terrain (well the terrain you see). Please do not select anything else (or you might drop cameras, buildings, etc, etc). Then double click this script. It will drop the selected elements to the exact altitude for them.
Take care, it takes a few seconds for each Human so don't select 1000 human at the same time, unless if you want to go and take a shower and take a coffee ;)
I mentionned 2 scripts initially but the script to "drop on low rez terrain" does not make sufficient effect on the border of the terrain. So maybe I'll keep only the "drop on High rez terrain" version of the script, which is the one solving the issue.
This script will solve the issue..... Well just let me know if it does not, but it should.
THE SCRIPT TO DROP YOUR PEOPLE ON THE TERRAIN WHEN THEY ARE TOO HIGH OR NOT ENOUGH HIGH IS ATTACHED HERE ====>
Yes, any bloom efefct is from the skydome - so far as I can recall I didn't monkey with the render settings for that. Good spot on seeing the 'plane, though!
It took about 30 to 40 times longer to place the people than it did to do the render, but only because I was a 'completeness geek' and selected every instane as a target for adding them!
Thanks for the info, this is a great bloom effect for an environment map!
Ahahaha!!! One people in front of each instance!!! Indeed, I think it is a bit too much!!! I think there must be 8000 or 10 000 elements in the scene. Yes often it will be longer to set up that to render ;)
Well the first advice, and I think now it is useless to tell it to you now, is that only ask for human beings where you will see them.
The second advice is that, what slows down the operation is not the fact of adding things. It is the viewport. It took me at least one week during the development of the product to understand why things were so fast when then began cities of 10 000 buildings, and then were more and more slow. It is because of the viewport ! When the scene goes heavy, the viewport enormously slows down the process (this is why in the main script to generate city it is better to ask for instance hide during building of big cities).
I think it is the same with human beings. So my advice would be, when you want to add a lot of things in a heavy scene, is that you swap the viewport to solid bounding box mode. This is what will allow the lighter viewport management and the fastest "add human" procedure. (the fastest "whatever you do" procedure anyway).
One reason I did it for all is, and don't laugh too hard, with the set as loaded you only see the 'real' objects not the instances, so cannot see which ones to pick to have the figures added to. I have plyed a bit with instancing and still need to get to grips with the viibilty options on them! Also, I was not sure where a gap in buildings or a slope of the terrain might (partially) reveal a figure: if you look closeely theer are visible figures right at the back of the scene.
I know what you mean about the viewport - many years ago Lotus Corp added a window update on/off option to the scripting language of 1-2-3 and that made some scriots, comparively, fly!
Yes, I understand your reasons :) The "Ah ah!" was not to poke fun.. It's just that I imagine the viewport handling with everything visible in !! You're right it it not easy to know sometimes if added human will be seen or not. In general what I did, and this is not necessarily what I recommend, is a two step add human. It was to select only the places I was sure to see them, then add 2/3 people in front on each elements of my selection. Then if I "felt" there could be other elements where human beings could be interesting, then I made a second selection for them, and add the other human beings. This doubles the number of facets required for the human beings, but since this is not a lot of facets, I think this is acceptable.
Yes, I looked for a way that the viewport ignored modifications until the end of the process, but I did not found this in the documentation. I don't say it does not exist, only that I did not find this:)
No worries, I think I read the 'ahah' in exactly the way you meant it!
The whole interface goes non responsive in the process of mult-selecting - to start with I did a 'select all' then went to deselect stuff like cameras ... whilst a few ice ages came and went I eventually (after the 2nd deseclt) dropped all the selectiosn and selected the base node of each instance ans used 'select children' which seemed to do the job much faster. Not sure how sluggisg the viewport would get if more instance detail was being shown - I may have to explore some options.
Well what I remarked is that whatever the viewport mode I use (solid bounding box or texture shaded), if I select all the elements of all the streets on big cities, it takes very long. I'm not sure it comes only from the viewport, I wonder if it does not come from a DS background process which is slow when you select more than, let's say, 5000 elements. Or maybe it simply takes 5000 times more time than when you select one.
Eventually if you think it can help I could make a "select all instances" script. It would be extremely easy to make, I would make a selection of everything with "instance" as a filter in the name. But I'm not sure if the selection process will be longer or not..
OK, only one way to know : try!!
OK I just made this new utility script.
For the ones who want to select all the nodes with "Instance" in the name, you can just run the script joined here. Indeed, with this script, it is fast (wrong actually it is long too - let's say it is easier), whereas when using the scene tab, it takes ages.
The script is gonna browse all the nodes of the scene and set as selected the ones with "Instance" in their names. It will not change the other elements you might have selected before.
edit : no it is long anyway, even the second time. I have 109 seconds for something like 10 000 elements, which is maybe normal, it makes around 1/10 second per element.
I let the script here for the ones who would like to have it anyway.
Thakns for the scripts - I'll give them a bash shortly.
I kow it'spart of a different set, but is there an easy way to get the populate with lo-rez humans script to work with the actual Medina city set?
hmmm... I don't understand the question.. I mean I don't understand what you want to do...
I'd like to sprinkle a few low-rez figures around the Medina cityscape (the actual city, not the generrated version(s)). gave it a try and soem figures appeared, all buried in floors or buildings and half of them as grey boxes.
OK. In this case the best thing is to use "nulls". Create 3 ou 4 null approximately where you want to place your low rez people (create/new null).
Then place them the right X, Y, Z near the place you want the figures to appear. The Y must be exactly on the "ground". Select all your nulls and then use the Add Human script.
Let me know if it helps you.
For the "grey boxes", this is something I just discover. I tell you why. The product has been corrected, not by myself, and I was not aware of the corrections. While the product was corrected, I gave the exact instruction to make the script safe at loading. These instructions have not been respected.
Since I managed only today to have the product, it's only today that I see the issue. The versions I have at home, which were not corrected, work perfectly. Great.
I'm gonna submit an update ASAP, I am sorry about that, there is nothing I could do better, if people break my work and don't let me check, it makes me really really nervous!
Oh, I hate it when that happens! Good luck in getting the corrected correction thrugh! :) Do the nulsl have to be ranamed to anything spcific or is teh script 'name agnostic'?
Oh, I hate when it happens too. I'm presently doing the corrections. I hate when a product I release has stupid issues like this. This should never happen.
The patch should be submitted tomorrow or the day after, including the script to drop people on cityscape terrain, and the update of the documentation.
The script is name agnostic. For each selected element (here it will be your nulls), it takes the origin of this element as the reference (Xo, Yo, Zo). You use the XRandom and ZOffset/Zrandom dials to define in wich "rectangle" the low rez human will be (if you clearly want to see this rectangle, click the button to add human plenty of times in the interface, and you will see it clearly plenty of people). So for the randomly loaded people :
Their X will be in the (Xo+XRandom, Xo-XRandom) range,
and their Z will be in the (Zo+Zoffset+Zrandom, Zo+Zoffset-Zrandom) Range.
The Y of the low rez human people will be Yo+Yoffset. So if you placed your null at the right height, just leave Yoffset at 0.
I hope this help.
THE FIRST UPDATE IS READY!
It includes :
- a patch of the data/V3Digitimes Folder in order to make sure that all the human beings are well loaded by the Add Human script (this was due to a correction I could not act on).
- the script to drop the human beings which would be to high or not high enough for the rendered terrain "Desert Cityscape Main Terrain".
- the update of the documentation to include why this script to drop human beings, and how to use it.
Tomorrow I will test the update again before submitting it (I should submit when US wakes up).
Worked great! Thanks for the quick response. I'm still learning to use this but like immensely what I've seen. I could easily see a whole series of different building types in the future using this same basic script.
Thanks for the nice feedback...
and for the future buildings... so do I!
Thanks for the script, V3Digitimes. It works very nicely.
Works on uneven terrain, too.
That really looks nice. The sloped terrain added a lot of interest, I think.
Gave it a try on a different landscape. I used Easy Environments Eternal Sands. Since Eternal Sands is 3DL, I selected 3DL props in the cityscape script. Lights are AoA's Distant and Ambient Lights. As warned in the PDF manual, the 83K polygon terrain was slow to populate, taking 27 minutes to place the buildings (4 streets of 15 houses each). But 3DL rendering was quick (<1 minute). Adding humans was also quick (I only selected a couple of buildings) and I manually positioned them after script placement so they were in the camera view. All in all, I liked how it turned out.
One note, the buildings were not in the camera view when the script was done, so I had to hunt for them. I couldn't spot them scrolling the camera so I used the perspective camera which was already focused on them.
This is just an amazing set--every bit of it.