Dinoyipi
|
  |
| Joined: 15 Jul 2011 |
| Total Posts: 198 |
|
|
| 18 Sep 2014 11:52 AM |
tl;dr: Add a way to perform Solid Modeling in-game.
(If this, or something similar, is already being planned by the ROBLOX staff, or is already implemented; could you kindly provide a reference and leave it at that? kthxbai)
====Introduction==== Solid Modeling is quite handy for building projects. Other limitations aside (like colors and collisions), I think one thing really holding it back is that it can only be used in the Studio. My suggestion is that methods be added to allow the use of CSG in-game. Ahead is my own suggestion for how it would work, which will be somewhat technical.
====Model:Union==== First thing would be to add a method to the Model Object that would perform a union operation on all parts therein:
local Union = game.Workspace.Model:CSGUnion()
This would only work in-game if it would work in-studio. (More information here: http://wiki.roblox.com/index.php?title=Solid_modeling#Limits) Attempting an invalid union will throw an error in the output.
====Part:CSGNegate==== Next would be a new method to any negate-able parts (Part, WedgePart, CornerWedgePart, NegateOperation, UnionOperation) that would negate the part for use in hollowing out other parts in CSG.
local NegativePart = game.Workspace.Part:CSGNegate()
====PartOperation:CSGSeparate==== Finally, a new method added to NegateOperation and UnionOperation to restore them, if desired, into their constituents.
local Model = game.Workspace.Union:CSGSeparate()
The above line of code, for example, would "undo" the above example for the CSGUnion method.
====Alternate Idea: game.CSGService==== While I was writing this post, I came up with the idea (probably a better one, in fact) of using a new Game Service for CSG. I haven't thought of the exact implementation, but it might work out as something like this:
game:GetSerivce("CSGService"):Union(game.Workspace.Model)
====Practical Application==== There could be a lot of uses for this, so I'll provide just one: Imagine a game that lets players forge custom-built weapons. Certainly possible at this time, but most weapons built would be collections of numerous, tiny parts; making them clumsy and laggy. By allowing Solid Modeling in-game, these weapons could consist of as few parts as one (maybe two or three for REALLY fancy ones).
====Conclusion==== Whew, this has definitely been one of my longer posts. For those who stuck with me through this entire post, and actually could make sense of my technobabble, kudos to you. Feel free to leave feedback. If you think this is a bad idea, please give reason(s) why. Short, negative replies like "no support" and "tl;dr" are not helpful, and can even be reported. |
|
|
| Report Abuse |
|
|
tinarg
|
  |
| Joined: 18 Jun 2010 |
| Total Posts: 4925 |
|
|
| 18 Sep 2014 12:00 PM |
I think it would be better if it was like this:
Table = {game.Workspace.Part1,game.Workspace.Part2,game.Workspace.Part3}
Union = Table:Union()
Union.Parent = game.Workspace
|
|
|
| Report Abuse |
|
|
Dinoyipi
|
  |
| Joined: 15 Jul 2011 |
| Total Posts: 198 |
|
|
| 18 Sep 2014 12:04 PM |
| I thought about that too, but I was concerned that it might be harder to keep track of. Then again, Table Manipulation is still something I'm learning, so I digress. |
|
|
| Report Abuse |
|
|
Dinoyipi
|
  |
| Joined: 15 Jul 2011 |
| Total Posts: 198 |
|
| |
|
Dinoyipi
|
  |
| Joined: 15 Jul 2011 |
| Total Posts: 198 |
|
| |
|
Dinoyipi
|
  |
| Joined: 15 Jul 2011 |
| Total Posts: 198 |
|
| |
|
|
| 18 Sep 2014 10:01 PM |
| Do tell how easy it would be to send this information to each user. It won't be. |
|
|
| Report Abuse |
|
|
wubbzy301
|
  |
| Joined: 15 May 2010 |
| Total Posts: 1188 |
|
|
| 18 Sep 2014 11:45 PM |
Useless:
- Unioning with scripts is very unpopular.
No offence. |
|
|
| Report Abuse |
|
|
tinarg
|
  |
| Joined: 18 Jun 2010 |
| Total Posts: 4925 |
|
|
| 19 Sep 2014 08:18 AM |
| I could use it and take a shot at making solid modeling building tools for those who don't use studio. |
|
|
| Report Abuse |
|
|
tinarg
|
  |
| Joined: 18 Jun 2010 |
| Total Posts: 4925 |
|
|
| 19 Sep 2014 08:18 AM |
| And don't shoot this down. Technically we'll get it sooner or later, users are just suggesting HOW it should be done. I think it should use tables. |
|
|
| Report Abuse |
|
|
Dinoyipi
|
  |
| Joined: 15 Jul 2011 |
| Total Posts: 198 |
|
|
| 19 Sep 2014 10:27 AM |
After giving it some thought, I think tables would be a really good idea. In addition to the code you mentioned earlier, there could be code like this (Underscores represent tab spacings for ease of reading):
parts = game.Workspace.Model:GetChildren() for i = 1, #parts do _if parts[i]:IsA("Part") then --Probably want to add more code here for Wedges, Negative parts, and other Unions. __parts[i]:ClearAllChildren() --Most children inside a part will disallow the union. _else __table.remove(parts, i) --Remove any non-union-able parts from the table _end end union = parts:CSGUnion() union.Parent = game.Workspace |
|
|
| Report Abuse |
|
|
|
| 21 Sep 2014 05:32 PM |
| Tables don't even make sense. You're trying to make two or more objects become a single object. With tables, you're still having one or more objects. |
|
|
| Report Abuse |
|
|
Udoxas
|
  |
| Joined: 04 Dec 2010 |
| Total Posts: 5212 |
|
|
| 21 Sep 2014 05:41 PM |
Support, I would love for games like Sandbox to have Soild Modeling.
| Current Status: Bored | Don't call me Udox or you die | I choke on pineapples | |
|
|
| Report Abuse |
|
|
Dinoyipi
|
  |
| Joined: 15 Jul 2011 |
| Total Posts: 198 |
|
| |
|
tinarg
|
  |
| Joined: 18 Jun 2010 |
| Total Posts: 4925 |
|
|
| 24 Sep 2014 09:11 AM |
| It's only a matter of time before this gets implemented... Everything has an associated API to it and solid modeling won't be an exception. |
|
|
| Report Abuse |
|
|
|
| 24 Sep 2014 09:56 AM |
I remember seeing a similar idea when solid modelling first came out, and apparently it would be added in the future after physics for it would come out. I guess I'll support anyway.
@wubbzy301 Something which isn't out yet obviously isn't popularly used. |
|
|
| Report Abuse |
|
|
|
| 24 Sep 2014 11:14 AM |
| Not everything has an API associated to it... I have no really access to how and when something will be garbage collected. |
|
|
| Report Abuse |
|
|
|
| 24 Sep 2014 11:32 AM |
game:GetService("CSGService"):Union(table)
:) |
|
|
| Report Abuse |
|
|
|
| 24 Sep 2014 01:46 PM |
You're still referencing multiple objects...
|
|
|
| Report Abuse |
|
|
|
| 24 Sep 2014 02:35 PM |
test this out:
union one part
it's possible
don't just say i'm not allowed to do it |
|
|
| Report Abuse |
|
|
|
| 24 Sep 2014 02:39 PM |
| I'm not saying you're not allowed to do it. I'm saying that you're giving a table and expecting it to be a single object. That doesn't make sense. In the end the table is still going be referencing every brick. |
|
|
| Report Abuse |
|
|
Dinoyipi
|
  |
| Joined: 15 Jul 2011 |
| Total Posts: 198 |
|
|
| 24 Sep 2014 03:10 PM |
@Above: I can see two workarounds for the problem. Take this code for example:
---------- local newtable = {game.Workspace.Part1, game.Workspace.Part2, game.Workspace.Part3}
if newtable then _print'Table exists' _print(newtable[1].Name) _print(newtable[2].Name) _print(newtable[3].Name) else _print'Table does not exist' end
local union = game:GetService("CSGService"):Union(newtable) --(Or however else it ends up turning out) union.Name = "Union1"
if newtable then _print'Table exists' _print(newtable[1].Name) _print(newtable[2].Name) _print(newtable[3].Name) else _print'Table does not exist.' end ----------
One option would be for the game to automatically set the table to nil when the unification method is called. If so, the example code would first print "Table exists", "Part1", "Part2", "Part3". Then the script would unify the part, before printing "Table does not exist".
Another option would be to simply have all of the table's entries now refer to the new union. In the code above, it would once again print "Table exists", "Part1", "Part2", "Part3" before unifying the part. Only this time, instead of printing "Table does not exist" after the unification, it would print "Table exists", "Union1", "Union1", "Union1"; reflecting that all three of the old table's entries now refer to the unified part.
I'm sure there could be other options, but I can only think of these two for now. |
|
|
| Report Abuse |
|
|
lah30303
|
  |
| Joined: 15 Feb 2008 |
| Total Posts: 10027 |
|
|
| 08 Nov 2014 07:58 PM |
This is something I want as well. Problem is, you will be able to keep a reference to the parts you unioned regardless of the syntax, which means you will be able to manipulate the position, size, ect. of the part after ROBLOX has calculated the decomposition of the union. Each time you change a part, it will have to recalculate that decomposition. I'm not saying it's undoable, but when you union a part in studio I'm guessing it turns it in to a single part for a reason. That being said, I do want them to implement this but if/when they do I hope they put a technical article on the blog explaining how things are done and if there are any effects on performance from moving around parts inside a union/negation.
Also, for syntax, I like the idea of having a CSGService. I think doing it with a table though is a bit superfluous. The parameters can simply be a tuple of parts. This way if you only want to union two parts you don't have to make a table for them, instead it would just look like this:
game:GetService("CSGService"):Union(Part1, Part2, Part3, ...)
If you have a table you want to union, you can simply use unpack(table). Arguably you could have it accept either tuples or tables, but that's not the way I've seen lua do things conventionally.
Another interesting problem comes up when you have CSG models negating other parts. Say I have P1 negating P2, and the resulting part negating P3. Say I want to separate P1 from P2 so that it is no longer negating P2. Should the now separated P1 be negating P3 or should it be separated from the entire CSG model?
From what I've seen in studio sometimes it gets very hard to predict how CSG will behave after multiple Unions/Negations, and after a certain point it can even start to get very glitchy. I think with scripting CSG models we will need to be able to have more control over how a CSG model will be formed. |
|
|
| Report Abuse |
|
|
lah30303
|
  |
| Joined: 15 Feb 2008 |
| Total Posts: 10027 |
|
|
| 08 Nov 2014 08:17 PM |
One thing I forgot to add. All methods should return the resulting part(s) unless they do not change which parts matter.
I saw this when you talked about unions where you could say this: local CSGPart = game:GetService("CSGService"):Union(P1, P2, ...)
But separations should also return the resulting parts. I'm not sure whether the return value should be a tuple or a table, I want to say tuple but since you can't know the number of parts you'll be getting, perhaps it should be a table.
local Parts = game:GetService("CSGService"):Separate(CSGPart)
Also, what if you want to separate two parts, but the CSGPart has three parts unioned with it? My first thought was to allow the separate method to accept the individual parts you want to separate, but then it doesn't know which part to keep unioned with the third part and which to separate completely. The way I see it, we have two options: 1. When the part given as the parameter is part of a larger union of parts, separate that part from the larger union, otherwise separate all parts that are unioned together to make that part.
2. Make another method. I'm not sure what the name should be... Split? Peel? Cut? Untie?
|
|
|
| Report Abuse |
|
|
Dinoyipi
|
  |
| Joined: 15 Jul 2011 |
| Total Posts: 198 |
|
|
| 13 Nov 2014 10:03 AM |
| @lah30303 Those are all very good points, but I don't expect to come up with a completely flawless implementation; that's ROBLOX's job (if they decide to go for this). I'm just putting this idea out there, along with a few possibilities for implementation as a proof of concept. |
|
|
| Report Abuse |
|
|