Zakładam, że masz na myśli generatory kodu własnościowego przeznaczone do konkretnego użytku wewnętrznego, ponieważ w przeciwnym razie kod maszynowy jest generatorem kodu. Ale proszę bardzo:
Myślę, że bardzo dyskusyjne jest to, że graf węzłów w Blueprints jest łatwiejszy w utrzymaniu i znacznie mniej podatny na błędy niż generowany przez niego kod GLSL / HLSL (i w innym przypadku musiałby być pisany odręcznie).
O wiele bardziej produktywne jest wymyślanie nowych shaderów, ponieważ otrzymujesz wizualną informację zwrotną w czasie rzeczywistym o tym, jak wygląda efekt końcowy po zmianie wykresu. Zdecydowanie wolałbym utrzymywać w ten sposób tysiące shaderów reprezentowanych za pomocą grafów węzłowych zamiast kodu GLSL / HLSL, i tak naprawdę lepiej znam pisanie GLSL / HLSL niż używanie Blueprints. Wydaje mi się, że jest to praktycznie niemożliwe, aby spowodować poważny błąd oprócz być może drobnej usterki wizualnej, którą prawdopodobnie złapałbyś od razu, ponieważ „język wizualny” nakłada rozsądne ograniczenia z często czystym funkcjonalnym stylem, który nie pozwala, powiedzmy, załamać moduł cieniujący, przynajmniej AFAIK (co prawda nie jestem ekspertem od Blueprints).
Nie ma nawet „kodu” do utrzymania. Po prostu umieszczasz węzły wewnątrz wykresu i rysujesz między nimi połączenia, i voila, generuje dla ciebie kod modułu cieniującego. Kto utrzymuje te rzeczy i mówi: „ Wiesz, moje życie byłoby o wiele łatwiejsze i miałbym o wiele więcej wolnego czasu, gdyby zostało to zapisane w kodzie GLSL zamiast korzystania z Blueprints ” . Prawdopodobnie nigdy.
To powiedziawszy, natknąłem się na część własnych generatorów kodów, które utrudniły życie, co spowodowało, że nauczyłem się tego głupiego meta-języka, który ma bardzo ograniczone korzyści, jeśli w ogóle, nad pisaniem kodu w języku wygenerowanego kodu. Dla mnie charakterystycznym znakiem generowania kodu, który jest gówniany, jest to, co robi niewiele więcej niż redukuje niewielką ilość płyty kotłowej i w rzeczywistości nie zmniejsza, powiedzmy, możliwości błędów. Wiesz, że to szczególnie gówniane, jeśli faktycznie wprowadza nowe sposoby powodowania błędów, których nie miał oryginalny język. Istnieją jednak przypadki generowania kodu, takie jak powyższe, w których wzrost wydajności jest tak ogromny, że drobiazgowe rzeczy, które kosztują olbrzymi czas, kosztują teraz grosze, że nikt nigdy nie użyłby ich i nie obejrzałby się za siebie.
Dla mnie jest bardziej uzasadniony argument za zastrzeżonym opracowaniem Blueprints wśród zespołu Epic, niż wiele zbędnych języków programowania dostępnych dla ogółu społeczeństwa, które ledwo wnoszą coś nowego do stołu.